> 2007/11/26, Scott Horowitz <email@example.com>:
>> Okay, here's a much improved version of the script. By default, it
>> will do fresh cvs checkouts of all archs (i.e. i686 and x86_64), so
>> I'd strongly recommend looking at the --help screen if that's not what
>> you want. You can point it at an existing abs tree instead if you
>> - Better accommodate x86_64 arch (thanks Eric for the useful info)
>> - Optional generation of graphical dep tree (requires pydot) (Cesar)
>> - Exclude makedepends from circular dependency checking
>> - Validate hierarchy of repos (e.g. that a core pkg doesn't depend on extra)
>> The only thing I'm not sure is useful is reporting "hierarchy
>> problems" for makedepends, e.g. if a package in core has a makedepend
>> in extra. Any opinions on if it should be kept or scrapped?
> Great work! Thanks!
>> Circular Dependencies
> Hah, this depends on coreutils just because of 'yes'. :-)
> It could be replaced with echo 'y'.
> this is already fixed in CVS HEAD
> Doesn't this script doesn't check that?
>> Repo Hierarchy for Makedepends
>> core/iputils depends on extra/jade
>> core/madwifi-utils depends on extra/sharutils
>> core/e2fsprogs depends on extra/bc
>> core/syslog-ng depends on extra/glib2
>> core/eventlog depends on extra/libol
>> core/madwifi depends on extra/sharutils
> I guess this should be moved to Core or revisited if these makedepends
> are needed.
> I knew only about glib2.
glib2 will be moved to core. It's currently in testing. I was thinking
about moving libol to core also as only syslog-ng needs it. The other
makedepends could be easily moved to core too as they only depends on core
>> extra/flac depends on community/xmms
> Huh? I don't use flac, but why a codec makedepends on a player?
Because the flac package includes a xmms plugin. It was already mentionned
on the dev ML and no one objected at the time.
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
arch mailing list