On Mon, 26 Nov 2007, Roman Kyrylych wrote:

> 2007/11/26, Scott Horowitz <stonecrest@gmail.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
>> 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
arch@archlinux.org
http://archlinux.org/mailman/listinfo/arch