FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-11-2008, 03:33 AM
Brian Harring
 
Default extending existing EAPI semantics

On Wed, Jun 11, 2008 at 04:20:04AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 19:56:23 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > * easy to shoehorn in for any profile.bashrc compliant manager
> > (portage/pkgcore); realize paludis is left out here (via it
> > intentionally being left out of PMS atm by ciaran), but
> > profile.bashrc *is* used by ebuild devs, thus it's a viable course (I
> > don't see profile.bashrc ever going away basically).
>
> If profile.bashrc is to be kept, it means massively reducing what can
> be done in there.

Restraint in use of profile.bashrc is a per community QA measure, not
a format restriction- think through the other "this is better for QA"
things I've suggested PMS wise, you've responded in the same manner.


> > * doesn't address versioning changes.
>
> Or indeed any change where the ebuild can't be visible to older package
> managers without breaking them.
>
> So basically it's not a solution at all.

Name a scenario.

Note, if the scenario is "pm doesn't support eapi function, and
doesn't support profile.bashrc", skip it, you're repeating what I
already laid out (which results in visible bash complaints, but the
manager still labeling the eapi inoperable).
~harring
 
Old 06-11-2008, 03:38 AM
Ciaran McCreesh
 
Default extending existing EAPI semantics

On Tue, 10 Jun 2008 20:33:11 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > If profile.bashrc is to be kept, it means massively reducing what
> > can be done in there.
>
> Restraint in use of profile.bashrc is a per community QA measure, not
> a format restriction- think through the other "this is better for QA"
> things I've suggested PMS wise, you've responded in the same manner.

Except that if profile.bashrc can tinker with package manager
internals, it has to be done in such a way that it works with all
package managers. So it has to be either Portage-specific or extremely
constrained.

> > > * doesn't address versioning changes.
> >
> > Or indeed any change where the ebuild can't be visible to older
> > package managers without breaking them.
> >
> > So basically it's not a solution at all.
>
> Name a scenario.

You already named one, and tried to gloss it over as not being the
complete showstopper that it is.

--
Ciaran McCreesh
 
Old 06-11-2008, 04:10 AM
Brian Harring
 
Default extending existing EAPI semantics

On Wed, Jun 11, 2008 at 04:38:01AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 20:33:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > > * doesn't address versioning changes.
> > >
> > > Or indeed any change where the ebuild can't be visible to older
> > > package managers without breaking them.
> > >
> > > So basically it's not a solution at all.
> >
> > Name a scenario.
>
> You already named one, and tried to gloss it over as not being the
> complete showstopper that it is.

Not exactly a show stopper; unknown versions are by and large
ignored due to paludis devs forcing it upon others. Ironic, that one.

You're also ignoring is that unlike the .ebuild-$EAPI approach,
this minor refinement leaves open options for replacement, and that
this option actually is likely far more agreeable then the filename
approach you've been trying to force since EAPI's inception (which
thus far hasn't taken hold despite positively massive noise from you).

One thing I'll note is that the .ebuild-$EAPI approach isn't the end
all fix to versioning extensions that y'all represent it as.
Essentially, what .ebuild-$EAPI allows is additions to version
comparison rules, no subtractions. Each new $EAPI *must* be a
superset of previous $EAPIs.

An example would be removal of float comparison rules; for <=eapi-1,
.006 < .6; Now if eapi-2 stated .006 == .6, that literally means that
the PM would have to maintain versioning rules per eapi level, meaning
that for an eapi1 ebuild, what it would match would differ from eapi2.
Aside from that being a cluster-fuck in the implementation, it's a
cluster-fuck for the dev trying to visualize what the manager is
actually up to.

Personally, that's a pretty nasty unstated gotcha. .ebuild-$EAPI
isn't the end all essentially, it has flaws just the same as other
solutions.

Marius/genone has advocated it in the past, and frankly I tend to
agree at this point- versioning rules are a repo level property by and
large, and the appropriate place to control that is at the repo level.

So... someone other then ciaran have a comment? We already know
ciarans views (hard not to when he has 2x greater posting ratio then
any other person)...

~harring
 
Old 06-11-2008, 04:25 AM
Mike Kelly
 
Default extending existing EAPI semantics

Brian Harring wrote:
One thing I'll note is that the .ebuild-$EAPI approach isn't the end
all fix to versioning extensions that y'all represent it as.
Essentially, what .ebuild-$EAPI allows is additions to version
comparison rules, no subtractions. Each new $EAPI *must* be a
superset of previous $EAPIs.


Uhh... no. Just like how older package managers which don't understand
how to read the EAPI from a filename suffix would basically ignore the
new ebuilds, any package manager that can, but doesn't recognize the
eapi of the new one, will just ignore it. It won't ever try to figure
out its version or anything, it'll just do nothing.


Also, there is absolutely no reason for all future EAPIs to be a
superset of old eapis. While paludis (and presumably pkgcore and
portage, I'm not as familiar with their code) has implemented EAPI=1 as
a few additions to EAPI=0, there is no reason that gentoo might not
decide to have EAPI=9000 some day, complete with artificial intelligence
that completely obsoletes USE flags, or some such thing (it's late, I
know the analogy sucks).



--
Mike Kelly
--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-11-2008, 04:34 AM
Luca Barbato
 
Default extending existing EAPI semantics

Mike Kelly wrote:

Brian Harring wrote:
One thing I'll note is that the .ebuild-$EAPI approach isn't the end
all fix to versioning extensions that y'all represent it as.
Essentially, what .ebuild-$EAPI allows is additions to version
comparison rules, no subtractions. Each new $EAPI *must* be a
superset of previous $EAPIs.


Uhh... no. Just like how older package managers which don't understand
how to read the EAPI from a filename suffix would basically ignore the
new ebuilds, any package manager that can, but doesn't recognize the
eapi of the new one, will just ignore it. It won't ever try to figure
out its version or anything, it'll just do nothing.


Also, there is absolutely no reason for all future EAPIs to be a
superset of old eapis. While paludis (and presumably pkgcore and
portage, I'm not as familiar with their code) has implemented EAPI=1 as
a few additions to EAPI=0, there is no reason that gentoo might not
decide to have EAPI=9000 some day, complete with artificial intelligence
that completely obsoletes USE flags, or some such thing (it's late, I
know the analogy sucks).




Assuming we won't move from flat file to db

lu - thinking of a darker future.


--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list
 
Old 06-11-2008, 05:16 AM
Brian Harring
 
Default extending existing EAPI semantics

You actually pretty much completely misinterpreted what I was saying,
so inserting the example back into the email and trying again...

On Wed, Jun 11, 2008 at 12:25:55AM -0400, Mike Kelly wrote:
> Brian Harring wrote:
> >One thing I'll note is that the .ebuild-$EAPI approach isn't the end
> >all fix to versioning extensions that y'all represent it as.
> >Essentially, what .ebuild-$EAPI allows is additions to version
> >comparison rules, no subtractions. Each new $EAPI *must* be a
> >superset of previous $EAPIs.
>
> >An example would be removal of float comparison rules; for
> ><=eapi-1, .006 < .6; Now if eapi-2 stated .006 == .6, that
> >literally means that the PM would have to maintain versioning rules
> >per eapi level, meaning that for an eapi1 ebuild, what it would
> >match would differ from eapi2. Aside from that being a
> >cluster-fuck in the implementation, it's a cluster-fuck for the dev
> >trying to visualize what the manager is actually up to.
>
> Uhh... no. Just like how older package managers which don't understand
> how to read the EAPI from a filename suffix would basically ignore the
> new ebuilds, any package manager that can, but doesn't recognize the
> eapi of the new one, will just ignore it. It won't ever try to figure
> out its version or anything, it'll just do nothing.

Here's the scenario:

1) EAPI1 defines foo-0.006 < foo-0.6.
2) EAPI2 redefine it so that foo-0.006 == foo-0.6
3) pkg 'a' has one version- '0.006'
4) pkg b-1, EAPI=1; DEPEND='<=a-0.006'
5) pkg c-1, EAPI=2; DEPEND='>=a-0.6'

Now, via EAPI1 definition, b-1 *must* match a-0.006; via EAPI2
definition, b-2 *must* match a-0.006 also. The only way the manager
can properly support this request is via getting the EAPI from the pkg
that specified that request.

Literally, the ordering of matches would have to vary dependant upon
the eapi of the pkg. This is a serious cluster fuck for any
implementation, and it's a pretty nice gotcha for ebuild developers.

The sane alternative here is that each successive EAPI release,
specifically the versioning rules, must be a superset of existing.
Via that you can induce a total ordering that works regardless of the
EAPI level of the generating pkg.

A scenario that is far more entertaining is how the manager is
supposed to handle the following:

1) EAPI2 defines 1.0-scm > 1.0
2) pkg 'a' has one visible version; 1.0-scm
3) pkg b-1 EAPI=1, DEPEND='<=a-1'
4) pkg c-1 EAPI=2, DEPEND='a'

What is the correct result here? Since b-1's versioning rules don't
know a damn thing about -scm, should it even be possible for it to use
that version? The only valid solution here (since EAPI1 does not
know, nor specify the ordering of -scm) is to bail.

If you're maintaing a total ordering (each EAPI a superset of the
last for versioning rules), you *could* retroactively decide on that
case.

Either way, point is that .ebuild-$EAPI doesn't magically solve
versioning changes. It hides away user visibility of it, but doesn't
solve the real issue.


> Also, there is absolutely no reason for all future EAPIs to be a
> superset of old eapis.

.ebuild-$EAPI-n requires all *versioning rules* to be a superset of
$EAPI=(n-1); if in doubt, re-read my example above.

Non versioning rules of $EAPI, no, no requirement to be supersets of
proceeding- but versioning under .ebuild-$EAPI, yes, it's required.

Cheers,
~harring
 
Old 06-11-2008, 05:22 AM
Ciaran McCreesh
 
Default extending existing EAPI semantics

On Tue, 10 Jun 2008 22:16:21 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > Also, there is absolutely no reason for all future EAPIs to be a
> > superset of old eapis.
>
> .ebuild-$EAPI-n requires all *versioning rules* to be a superset of
> $EAPI=(n-1); if in doubt, re-read my example above.

No it doesn't. It requires that versions be mappable to a single,
enumerable master version format. Big difference. You could quite
happily add -scm and remove _p in future EAPIs, for example.

--
Ciaran McCreesh
 
Old 06-11-2008, 05:33 AM
Brian Harring
 
Default extending existing EAPI semantics

Kindly respond to the rest of the email first of all...

On Wed, Jun 11, 2008 at 06:22:31AM +0100, Ciaran McCreesh wrote:
> On Tue, 10 Jun 2008 22:16:21 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > Also, there is absolutely no reason for all future EAPIs to be a
> > > superset of old eapis.
> >
> > .ebuild-$EAPI-n requires all *versioning rules* to be a superset of
> > $EAPI=(n-1); if in doubt, re-read my example above.
>
> No it doesn't. It requires that versions be mappable to a single,
> enumerable master version format. Big difference. You could quite
> happily add -scm and remove _p in future EAPIs, for example.

Lay out how .006/.6 would work properly *per* eapi. As I clarified in
my last email, the master would vary dependant on the eapi- which
isn't valid unless you're retroactively overriding the versioning
rules of an eapi.
~harring
 
Old 06-11-2008, 05:37 AM
Ciaran McCreesh
 
Default extending existing EAPI semantics

On Tue, 10 Jun 2008 22:33:41 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Lay out how .006/.6 would work properly *per* eapi. As I clarified
> in my last email, the master would vary dependant on the eapi- which
> isn't valid unless you're retroactively overriding the versioning
> rules of an eapi.

"Must be a superset" being wrong does not mean "entirely arbitrary
changes are OK" is right.

--
Ciaran McCreesh
 
Old 06-11-2008, 05:46 AM
Luca Barbato
 
Default extending existing EAPI semantics

Ciaran McCreesh wrote:

On Tue, 10 Jun 2008 22:33:41 -0700
Brian Harring <ferringb@gmail.com> wrote:

Lay out how .006/.6 would work properly *per* eapi. As I clarified
in my last email, the master would vary dependant on the eapi- which
isn't valid unless you're retroactively overriding the versioning
rules of an eapi.


"Must be a superset" being wrong does not mean "entirely arbitrary
changes are OK" is right.


You have actual usecases (eventually not thin air), which is your
counterproposal that works for them?


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

--
gentoo-dev@lists.gentoo.org mailing list
 

Thread Tools




All times are GMT. The time now is 08:18 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org