On Mon, 26 Nov 2007, Roman Kyrylych wrote: > 2007/11/26, Scott Horowitz <[EMAIL PROTECTED]>: >> 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 >> wish. >> >> Changes: >> - 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 >> ----------------------- > >> shadow>coreutils>shadow > Hah, this depends on coreutils just because of 'yes'. :-) > It could be replaced with echo 'y'. > >> coreutils>pam>db>coreutils > 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 packages. > >> 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 [email protected] http://archlinux.org/mailman/listinfo/arch
