-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/10/12 01:56 PM, Ciaran McCreesh wrote: > On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius > <a...@gentoo.org> wrote: >> On 30/09/12 05:53 PM, Ciaran McCreesh wrote: >>> On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring >>> <ferri...@gmail.com> wrote: >>>>> The second is that it starts the conceptual shift from >>>>> "cat/pkg is a build dep, and cat/pkg is a run dep" to >>>>> "cat/pkg is a dep that is required for build and run". >>>> >>>> Fairly weak argument at best; you're claiming that via >>>> labels, "contextually they know it's these deps" in >>>> comparison to via dep:build "contextually they know it's >>>> exposed only in build". >>>> >>>> Same difference. >>> >>> It's rather a big deal now that we have := dependencies. >>> > >> So you would using your labels syntax, specify an atom with a := >> dep using certain labels and the same atom without ':=' on other >> labels? I don't quite follow what you're getting at here as to >> how this is a big deal.. > > A := only makes sense for a dependency that is present both at > build time and at runtime. Currently, the only place you should be > seeing a := is on a spec that is listed in both DEPEND and > RDEPEND. > > Conceptually, the := applies to "the spec that is in both DEPEND > and RDEPEND". But with the current syntax, there's no such thing as > "the spec that is in both". There are two specs, which happen to > be identical as strings, one in DEPEND and one in RDEPEND, and > there's no way for the two to be associated. >
Current syntax = *DEPEND, yes. Completely agree. In relation to Brian's proposal for DEPENDENCIES, tho, the two specs which happen to be identical strings would be rolled out from the same - -actual- string in the ebuild, and so, I don't see any such 'big deal' between the ability to conceptually express what's going on via his syntax and your labels. Unless i'm missing something, 'same difference' still fits.. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBrLYIACgkQ2ugaI38ACPBb4gD+KnH0izbhJZuhm0JD1cHG6s0D 4/0gxZk3Z+TEy9I0W84A/1Yt0ilqJ0SfNTHr9P6hjQkUvLsHzPzkh4Kiz8VMah/w =8amf -----END PGP SIGNATURE-----
