-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 07 Sep 2012 10:50:40 -0400 Ian Stakenvicius <a...@gentoo.org> wrote: > On 07/09/12 07:45 AM, Ciaran McCreesh wrote: > > [ Snip! ] Note also how the foo-related things, the bar-related > > things etc cannot be grouped together by their fooness or barness, > > but are rather grouped by their DEPENDness and RDEPENDness. > > > > [ Snip! ] > > > > So here's what DEPENDENCIES solves: > > > > Firstly, it allows developers to group together foo-related > > dependencies and bar-related dependencies by their fooness and > > barness, not by their role. [ Snip! ] *** It does it by replacing > > the concept of "a package has build *** dependencies, run > > dependencies, etc" with "a package has *** dependencies, and each > > dependency is applicable at one or more of *** build time, run tme, > > etc". > > And this is the specific point that I don't like about DEPENDENCIES > versus *DEPEND. As a developer, I personally find it much more > straight-forward to fill in the deps needed for each role, rather than > specifying the role(s) that each dep will play a part in.
Have you tried doing both? You may find you're just arguing from familiarity, and that after having worked the other way for a few packages, that the advantages become clearer. The wide-spread use of hacks like COMMON_DEPEND are a pretty strong indication that people *do* think in something closer to a DEPENDENCIES-like fashion. In particular, I find it hard to believe that you think "ok, so I've got a build dependency upon >=cat/pkg-2.3[foo]" and then independently work out "ok, I've got a run >dependency upon >=cat/pkg-2.3[foo]". - -- Ciaran McCreesh -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBKC6cACgkQ96zL6DUtXhG94gCgmXP0C+nAItSnCTIMoeJHzqzK AyYAniXFZR5mJrBtuGI10dWt0nuJFhwc =vZBn -----END PGP SIGNATURE-----
