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, 01:15 AM
Luca Barbato
 
Default Preliminary Meeting-Topics for 12 February 2009)

Ciaran McCreesh wrote:

Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.


As said long ago the glep doesn't tell enough:

"The current way of specifying the EAPI in ebuilds is flawed. In order
to get the EAPI the package manager needs to source the ebuild, which
itself needs the EAPI in the first place. Otherwise it imposes a serious
limitation, namely every ebuild, using any of the future EAPIs, will
have to be source'able by old package managers and hence there is no way
to do any of the following:


* Change the behaviour of inherit in any way (for example, to
extend or change eclass functionality).

* Add new global scope functions in any sane way.
* Extend versioning rules in an EAPI - for example, addition of
the scm suffix - GLEP54"


Let's try to start with a common workflow for the user:
- an user with an ancient version of portage syncs
- it requires a package
- it looks at the cache ($portdir/metadata/cache/)
- picks the best entry from the ones showing an eapi it understands
- keeps going.

Apparently we do not have any issue...

Now problems:
1- the cache could get a non compatible change
2- the user triggers a metadata cache regeneration
-> the ebuild is sourced -> portage could fail or do something
unpredictable

3- overlays do not provide metadata cache
4- A package manager different from portage do not use the provided cache.

Solutions:
1- move the incompatible cache out of ancient portage scope (like in a
separate directory)
2- The user will get unpredictable behavior, but portage tell you when
upgrading is needed...

3- you'd have to disable them
4- unsupported.

Apparently for this side we don't have much to do if we get a valid cache.

Ebuilds have to be added to portage so here the workflow for the developer:

- new ebuild is sourced
- cache is generated
- manifest is built

In this case we have a problem if the source step is a single one,
portage won't know in advance how to behave.


So the first step has to be split in two:
- first portage discovers which is the eapi version
- then behave as defined by the eapi

The problem is that right now sourcing is done by having an instructed
bash. So the simplest way to get the first step done is parsing the
ebuild file with something different like file(1) and then instruct bash
and do the parsing.


This will solve the issue for the developer.

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.


The fact the glep itself is too much terse doesn't help acknowledging
the problems it aims to solve and the fact it fails to state actual
issues that may need a solution doesn't make it worth the effort and
disruption it would lead.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
 
Old 02-23-2009, 07:38 AM
Tiziano Müller
 
Default Preliminary Meeting-Topics for 12 February 2009)

> 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.)
 
Old 02-23-2009, 08:25 AM
Alistair Bush
 
Default Preliminary Meeting-Topics for 12 February 2009)

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.

Personally I don't see what the problem is with simply implementing
GLEP-55. It's the best solution.
It should be pretty simple to implement too. Certainly it wouldn't be
anymore difficult to implement than your solution.

Maybe once zmedico finishes his latest development push I will attempt
to implement it.
 
Old 02-23-2009, 09:02 AM
Tiziano Müller
 
Default Preliminary Meeting-Topics for 12 February 2009)

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.

> Personally I don't see what the problem is with simply implementing
> GLEP-55. It's the best solution.
> It should be pretty simple to implement too. Certainly it wouldn't be
> anymore difficult to implement than your solution.

I fully agree.
 
Old 02-23-2009, 09:28 AM
Douglas Anderson
 
Default Preliminary Meeting-Topics for 12 February 2009)

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.
 
Old 02-23-2009, 12:21 PM
Luca Barbato
 
Default Preliminary Meeting-Topics for 12 February 2009)

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 main point again what is proposed in glep-55 is it that isn't
invasive and non-transparent to users and developers.


As stated in the analysis, the user side is already covered by the fact
users use the cache, the developer side would require a two stage
sourcing when committing to remain transparent.


What we need to balance is if the invasive proposal is simpler than
having a two stage sourcing done.


lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
 
Old 02-23-2009, 12:50 PM
Ciaran McCreesh
 
Default Preliminary Meeting-Topics for 12 February 2009)

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.

--
Ciaran McCreesh
 
Old 02-23-2009, 12:57 PM
Ciaran McCreesh
 
Default Preliminary Meeting-Topics for 12 February 2009)

On Mon, 23 Feb 2009 03:15:03 +0100
Luca Barbato <lu_zero@gentoo.org> wrote:
> Let's try to start with a common workflow for the user:
> - an user with an ancient version of portage syncs
> - it requires a package
> - it looks at the cache ($portdir/metadata/cache/)
> - picks the best entry from the ones showing an eapi it understands
> - keeps going.
>
> Apparently we do not have any issue...

...assuming the metadata cache is valid. That isn't always the case.

> 2- The user will get unpredictable behavior, but portage tell you
> when upgrading is needed...

Not if the version you'd need to do metadata generation is ~arch it
doesn't.

> 3- you'd have to disable them

Yes, tell everyone to disable all the overlays that make use of a few
features only in ~arch package managers... That'll work...

> In this case we have a problem if the source step is a single one,
> portage won't know in advance how to behave.
>
> So the first step has to be split in two:
> - first portage discovers which is the eapi version

...which it can't do, because it doesn't know the EAPI.

> The problem is that right now sourcing is done by having an
> instructed bash. So the simplest way to get the first step done is
> parsing the ebuild file with something different like file(1) and
> then instruct bash and do the parsing.

file(1) can't parse ebuilds. Only an ebuild implementation can parse
ebuilds, and only if it already knows the EAPI.

> 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.

There's no surprise at all. It's extremely clear.

--
Ciaran McCreesh
 
Old 02-23-2009, 01:23 PM
Ciaran McCreesh
 
Default Preliminary Meeting-Topics for 12 February 2009)

On Mon, 23 Feb 2009 06:15:25 -0800
Brian Harring <ferringb@gmail.com> wrote:
> > 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.

It was checked back when 55 was originally written. If it's broken now,
it's a breakage since then...

> 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...

Well yes, but that's never realistically going to happen. 55's one of
the few repository format fixes that can happen in a reasonable
timeframe.

--
Ciaran McCreesh
 
Old 02-23-2009, 01:28 PM
Richard Freeman
 
Default Preliminary Meeting-Topics for 12 February 2009)

Douglas Anderson wrote:

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.


I got the impression that if anything there is a desire to allow EAPIs
to change more offen, and not less. And these changes could become more
dramatic. I'm not sure this is actually a bad thing (within reason - we
do need to have clear specifications for anything that hits production
so that we don't have a package manager mess).


Also - keep in mind that EAPIs do not need to be numbers and are not
ordered. You could have ebuild-i_am_a_furry_monkey or
ebuild-<bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays>.
Sure - hopefully the names will be more sensible and somewhat uniform,
but we're not necessarily just talking about adding a number to the
extension.


I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care, bzip2
doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so
doesn't care. I'm sure that in at least some of these cases they end up
parsing parts of the file twice - once to figure out what it is, and the
second time to actually handle it. I'm actually hard pressed to think
of any unix-based software that uses the filename to store a mandatory
file format versioning specifier of some kind.


This seems to me to be a solved problem. You put a header in a file
that tells you how to read the file. Headers are split into fields and
if a program doesn't know what to do with a field it ignores it (or if
the header so instructs it doesn't even try to parse the file). This
should be easy to do and keep the file bash-compatible. Just stick a
comment line close to the top of the file and put whatever you want on
it. You could also stick something in metadata.xml (although this makes
working with ebuilds outside of a repository more difficult). You run
the file through an algorithm to find out what the EAPI is, and then
source it if appropriate.


Sure, if you make some major change analogous to switching from the .rpm
to the .deb package format then maybe an extension change would make
sense. But, why expose the inner workings of the package file format to
the filesystem?
 

Thread Tools




All times are GMT. The time now is 12:48 PM.

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