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.
> > (And I have a sneaking recollection of PMS not documenting this
> > properly...)
>
> Yes, I think PMS is pretty silent about this. I think it doesn't even
> say that in phase functions the contents are implementation-defined.
That's covered under the general rules for environment variables. The
issue is that PMS doesn't make a good distinction between the metadata
variable's value and the environment variable value. The wording that's
in there currently dates back to how things worked a very long time ago.
> > > 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...
> > > And we will have to convert them back to old-style dependencies
> > > anyway. For the sake of compatibility with external tools.
> >
> > No, external tools are required to be EAPI aware. If they're not,
> > then the external tools need fixing.
>
> Changing package manager API like that between EAPI is just bad. You
> know that, don't you?
Your choices are to make the package manager API abstract out this sort
of thing, or to require client updates for a new EAPI. And as it's
fairly hard to predict what's going to be in a new EAPI, being too
abstract is pretty much a lost cause.
You can't simply convert new concepts to old concepts, since there's no
pre-EAPI-5 concept of what any of these new dependency types are.
Treating an HDEPEND or an IDEPEND as a DEPEND is just wrong.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
