-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. Although I realize that technically I could still do that (have the dep list be role-centric rather than dep-centric), given that the point of this change is (as stated above) to organize deps the other way, I can't really get behind the idea. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBKCcAACgkQ2ugaI38ACPDARgD+Inqa+/o1kTqlfuf7gC6wa3Da YAmj/F7Glno1QuzALboA/1l/XCbTr27XBGv7ULcvN0rdqqrBmarA8CgsySQiZRUB =Xwaz -----END PGP SIGNATURE-----
