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 02-23-2009, 07:52 AM
Brian Harring
 
Default Preliminary Meeting-Topics for 12 February 2009)

On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
> > What is proposed in glep-55 seems to aim to solve both issues at the
> > same time (it isn't stated) by switching file extension every time the
> > eapi is changed. This is slightly against the principle of the least
> > surprise and apparently is disliked by enough people to lead the
> > situation to be discussed in the council.
> >
>
> Instead of switching file extension every time the eapi is changed you
> could also increment it only when a new EAPI breaks sourcing the ebuild
> compared to the requirements of the prior EAPI.
> (This way you'd in fact split EAPI into a major- and a minor-version.)

Complicates the implementation (annoying), but more importantly
negates one of the features of g55- being able to tell via the
extension if the manager supports that EAPI.

Honestly, the issue isn't breaking sourcing (literally unable to
source it) of the ebuild as much as sourcing it *wrong*- simplest
example, new metadata key is added in eapi 1.3, compliant
implementations have to pull that key out of the env and put it in the
cache. Sourcing on the surface, would succeed- but the results would
be worthless (it'd basically be similar to the situation now).

~brian
 
Old 02-23-2009, 11:26 AM
Brian Harring
 
Default Preliminary Meeting-Topics for 12 February 2009)

On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote:
> On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller <dev-zero@gentoo.org> wrote:
> > Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush:
> >>
> >> Tiziano Müller wrote:
> >> >> What is proposed in glep-55 seems to aim to solve both issues at the
> >> >> same time (it isn't stated) by switching file extension every time the
> >> >> eapi is changed. This is slightly against the principle of the least
> >> >> surprise and apparently is disliked by enough people to lead the
> >> >> situation to be discussed in the council.
> >> >>
> >> >
> >> > Instead of switching file extension every time the eapi is changed you
> >> > could also increment it only when a new EAPI breaks sourcing the ebuild
> >> > compared to the requirements of the prior EAPI.
> >> > (This way you'd in fact split EAPI into a major- and a minor-version.)
> >> >
> >>
> >> Doesn't that just add extra complexity for no gain.
> > Yes, sure. I was just looking for a solution for the "we have countless .eapi-X after 10 years" problem.
>
> No one wants to be working with ebuild-29 or something like that in a
> few years and trying to figure out which feature came in which EAPI.
> Instead of bumping EAPI for each little change, save them up and bump
> no more than once a year or less, each bump bringing in some major new
> feature. With a little common sense and planning, we could make this a
> non-issue and give ebuild authors and PM devs alike a little time to
> get used to each change.

There also is the angle that deploying g55 requires waiting at least a
full stage release (~year, at least by the old standards) to ensure
people aren't screwed by the repository changing formats
(unversioned!) under their feet.

I'd point out that g55 isn't even accepted (search the archives for
the debates), but folks seem to be ignoring that and the issues of
just flipping the switch...

~harring, aka the "version the farking repo format so stuff like this
can be done cleanly" guy
 
Old 02-23-2009, 12:40 PM
Thomas Anderson
 
Default Preliminary Meeting-Topics for 12 February 2009)

On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
> Tiziano M??ller wrote:
>>> What is proposed in glep-55 seems to aim to solve both issues at the same
>>> time (it isn't stated) by switching file extension every time the eapi is
>>> changed. This is slightly against the principle of the least surprise and
>>> apparently is disliked by enough people to lead the situation to be
>>> discussed in the council.
>>>
>> Instead of switching file extension every time the eapi is changed you
>> could also increment it only when a new EAPI breaks sourcing the ebuild
>> compared to the requirements of the prior EAPI.
>> (This way you'd in fact split EAPI into a major- and a minor-version.)
>
> Makes you getting to have to do the two stage source again AND you get
> another non obvious condition "Should I bump the eapi internally or the
> filename?"

The glep is quite clear on that point.

> The main point again what is proposed in glep-55 is it that isn't invasive
> and non-transparent to users and developers.

It's not all that invasive. All that changes is that the EAPI goes at
the end of the filename and you don't set it in the ebuild. Developers
should be able to keep up with this, and if a user asks it's easy enough
to say that "it's a new version of ebuild, it has newer features see
www.blah.org/blah for details". And really, users already ask what EAPI
is so it's not that much headache.

--
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------
 
Old 02-23-2009, 12:45 PM
Duncan
 
Default Preliminary Meeting-Topics for 12 February 2009)

Brian Harring <ferringb@gmail.com> posted 20090223085232.GA6492@hrair,
excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800:

> On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote:
>> [quoting...]
>>> What is proposed in glep-55 seems to aim to solve both issues at the
>>> same time (it isn't stated) by switching file extension every time
>>> the eapi is changed. This is slightly against the principle of the
>>> least surprise and apparently is disliked by enough people[...]
>>
>> Instead of switching file extension every time the eapi is changed you
>> could also increment it only when a new EAPI breaks sourcing the ebuild
>> compared to the requirements of the prior EAPI. (This way you'd in fact
>> split EAPI into a major- and a minor-version.)
>
> Complicates the implementation (annoying), but more importantly negates
> one of the features of g55- being able to tell via the extension if the
> manager supports that EAPI.

That makes sense, but from my observation, the biggest resistance is
coming from potentially unlimited changes to the extension. That rubs
some people strongly enough the wrong way to have folks threatening to
leave over it, etc. If it must be, it must be, but obviously, if there's
a /reasonable/ way to avoid it, we should.

Way back when this first came up, I asked a simple question and IIRC
wasn't satisfied with the answer. Since the elements of it have been
proposed separately, perhaps it's time to ask about the combination once
again, as it seems to me to solve both the technical and aesthetic
issues, tho admittedly it does have a bit of the "complicates the
implementation" problem.

As I understand it, the nastiest technical problem is currently the
chicken/egg issue of needing the EAPI to source the ebuild... to /get/
the EAPI. Above, we have what amounts to a major/minor EAPI proposal,
stick the major in the extension (or as a variant, the pre-extension
filename), with it bumped only when the format changes enough to require
pre-source knowledge of the change.

Elsewhere, someone proposed strenthening the format rules by hard-
specifying a location and format for the EAPI line, say line two of the
ebuild and in a format specific enough to be parsed /without/ sourcing
the ebuild, thus providing a pre-source method for grabbing the EAPI.
The shoot-down when originally suggested was that this isn't flexible
enough. It's also arguably less efficient since one has to access the
file twice, first to get the EAPI, then to actually source the file.
Unfortunately the below suggestion doesn't avoid that.

Combining the two ideas, we get:

Why not put the "EAPI-major" aka "pre-parse-EAPI" in that hard-specified
in-file location, thus giving the package manager a method to grab it pre-
source, then allow more flexibility on the "EAPI-minor" aka
"post-parse-EAPI"?

FWIW, all EAPIs to date have been EAPI-minor/post-parse, precisely
/because/ of the need-the-EAPI-to-source-to-get-the-EAPI issue. This
would eliminate that issue, providing both the necessary pre-source
(major) EAPI solution and flexibility on the post-source (minor) EAPI.
It would also avoid the so controversial aesthetic issue, maintaining the
traditional .ebuild extension.

The negative, however, as mentioned, is that of efficiency. It'd be
necessary to access the file twice, pre-source to get the EAPI-major,
then the source to fill in all the details. Putting just the EAPI-major
in the filename/extension would avoid the first access (a dir listing
would suffice) and using the filename for the EAPI entirely would in some
cases possibly avoid accessing the file itself entirely -- at the expense
of EAPI flexibility and aesthetics.


Meanwhile, a status/process observation, if I may. Given the efficiency
negative of putting the EAPI anywhere /but/ the filename and the way the
debate has gone, GLEP-55 or something close to it (using the filename for
EAPI) would appear headed toward ultimate approval, however slow it seems
to be getting there.

The major blocker would appear to be that the GLEP as-is simply doesn't
sufficiently address everything that has come up in the discussions. As
such, it's not clearly and sufficiently enough worded for the council to
feel comfortable approving it. Based on council logs and discussion, I
get the STRONG impression that they are pretty much /begging/ the
proponents to address this issue, updating the GLEP as appropriate, so
they can /finally/ get out of the eternal debate stage and vote it up or
down (presumably up as it doesn't appear they have a viable alternative
either) on its merits, and the PMs can get it implemented and both the
council and Gentoo can move on.

Unfortunately, due to "personnel issues", apparently there's currently
nobody filling the triple qualifications of being (1) a strong enough
proponent to bother, (2) a PM dev or other with sufficient grasp of the
issues to actually /do/ the work, and (3) a Gentoo dev with the necessary
authorization and access privs. Until that changes and the GLEP is
updated appropriately, we seem locked in the endless loop of discussion
going nowhere, fast!

So it seems the proponents have a clear way forward, should they wish to
pursue it. Until they do, we might as well quit the discussion as it's
not accomplishing anything, no matter how good it could be or how much of
a block the failure to implement is on future improvements. The council
seems to have been clear enough, even /I'm/ getting that much.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
 
Old 02-23-2009, 01:15 PM
Brian Harring
 
Default Preliminary Meeting-Topics for 12 February 2009)

On Mon, Feb 23, 2009 at 01:50:10PM +0000, Ciaran McCreesh wrote:
> On Mon, 23 Feb 2009 04:26:49 -0800
> Brian Harring <ferringb@gmail.com> wrote:
> > There also is the angle that deploying g55 requires waiting at least
> > a full stage release (~year, at least by the old standards) to ensure
> > people aren't screwed by the repository changing formats
> > (unversioned!) under their feet.
>
> No it doesn't. It's transparent to users using an older package manager.

Would be useful if someone pulled older portage versions and checked
exactly what they do in this case- explode, behave, etc (manifest
behaviour included). It's been several years, but I recall portage
having problems at the onset of EAPI w/ it.

Beyond that, what I was stating was that the user doesn't get told
"sorry, your manager is too old, upgrade"- kind of an unobvious
failing.

Frankly, in terms of g55 I don't particularly care if it were
implemented- although I'd rather see it go in a seperate repo along w/
the dozen other fixups needed, preferably starting w/ overlays...

~harring
 

Thread Tools




All times are GMT. The time now is 08:09 PM.

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