On Thu, 6 Sep 2012 09:00:40 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Thu, 6 Sep 2012 09:39:25 +0200
> Michał Górny <mgo...@gentoo.org> wrote:
> > On Thu, 6 Sep 2012 06:58:51 +0100
> > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> > > On Wed, 5 Sep 2012 18:15:43 +0200
> > > Michał Górny <mgo...@gentoo.org> wrote:
> > > > If we really want to go this route, then please at least require
> > > > explicit label at start of DEPENDENCIES. And the same when
> > > > appending to DEPENDENCIES -- just so 'unlikely' mistakes will
> > > > leave us with hours of debugging.
> > >
> > > We should take the exheres-0 rules for labels and eclasses, which
> > > limit labels' scopes to blocks, and which introduce an extra ( )
> > > block around the outside when doing eclass variable merging.
> >
> > Because? I believe we should take 'Gentoo rules', including required
> > explicit build+run at the start.
>
> You mean, you want to invent some new rules that don't quite work,
> rather than using the ones that do... The whole "initial labels" thing
> isn't an issue for exheres-0, since rather than appending, the
> resulting metadata variable ends up with extra ( ) blocks like this:
>
> (
> stuff/from-the-exheres
> )
> (
> stuff/from-exlib-1
> )
> (
> stuff/from-exlib-2
> )
>
> so there's no possibility of labels ending up applied to the wrong
> thing.
>
> If you just append, you'd have to have some way of validating that
> eclasses all individually specify an initial label. That's not
> something that can easily be done.
In that format there is not a single thing which *can be done easily*.
But what I was saying is that I dislike the implicit 'no label ==
build+run'. It's unclear, very unclear.
Why the heck:
( foo/bar )
introduces another label than:
use? ( foo/bar )
?
> > > > Remember that this requirement will actually cause migration to
> > > > EAPI 5 to be even harder than to any previous EAPIs. Migrating a
> > > > single ebuild will require rewriting the dependencies, and
> > > > migrating an eclass will require adding a lot of dirty code.
> > >
> > > Migrating to EAPI 5 requires rewriting dependencies anyway if
> > > we're adding in HDEPEND. Also, earlier EAPIs have introduced new
> > > phase functions, which is a far ickier change for ebuilds than
> > > this.
> >
> > Do you really believe in HDEPEND in EAPI 5? I've already postponed
> > this in my mind. Also, not every single ebuild will actually need
> > it.
>
> *shrug* if all the new *DEPEND stuff ends up in EAPI 6, then there's
> no point in DEPENDENCIES for EAPI 5. But we'll have to sort this out
> sooner or later...
Yes, there's more time for a meaningful discussion without switching
everything upside-down just because you did it.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
