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-24-2009, 09:49 PM
Ferris McCormick
 
Default Collecting opinions about GLEP 55 and alternatives

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a useful
> experiment to see if we can control ourselves
>
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage

This is GLEP-55 I think, and it is my preference. It seems to solve
the problem that the glep sets out to solve and has no effect on
current portage. I don't claim that it's beautiful or perfect, but I
have not seen a better alternative, either. It also has going for it
the fact that some number of people have already thought through it and
Piotr went to the effort of writing it up as a proposal, so it has had
more thought put into it than alternatives. I do not find the
arguments against it persuasive, so I'd say do this and be done with
it. We can argue forever for better alternatives, but I don't see that
we are getting very far with that approach. Just my opinion, of course.

> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

This one's OK with me, too, if people prefer it.

>
> 3) EAPI in locked down place in the ebuild

I generally dislike this sort of thing, and I think it puts more of a
strain of the ebuild developers. But then, I'm not an package
developer, so my opinion with respect to this is not worth much. I'd
just rather see the EAPI visible in the file name than have to read the
ebuild to find it, and I guess the overhead argument is that it's
easier on portage not to have to do that, too.

> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>

I don't see why this is better than the glep 55 proposal???

> b) new subdirectory like ebuilds/

Yuch.

> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait
>
> Regards,
> Petteri
>

Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
 
Old 02-24-2009, 10:48 PM
Ryan Hill
 
Default Collecting opinions about GLEP 55 and alternatives

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a
> useful experiment to see if we can control ourselves
>
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage

#1

Though I also wouldn't mind separate EAPI and ebuild-format versions,
EAPI limited to the stuffing and EBV for the bird. I'd expect the
number of times we'll need to make global changes will be few.
(fewer than EAPI changes anyways)

> b) .<eapi>.ebuild
> - current Portage does not work with this

#2

> c) .<eapi>.<new extension>
> - ignored by current Portage

This would be #2 if I could think of a better extension than .ebuild

.esh
.gentoo
.rebuild
.fbuild
.eawesomeness

(not seriously)

> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait

#3

--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
 
Old 02-24-2009, 11:38 PM
Richard Freeman
 
Default Collecting opinions about GLEP 55 and alternatives

Petteri Räty wrote:

3) EAPI in locked down place in the ebuild
- Allows changing global scope
- EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache


I don't see how this follows. The PM can compare the mtime on the file
with the time the cache was updated and refresh if needed. Or we could
require users to manually refresh the cache if they modify an ebuild.



- Does not allow changing versioning rules unless version becomes a
normal metadata variable


I don't see how this follows. You can put any version in the filename
that you like just as with the EAPI in the filename approach. A package
manager won't process the filename if it doesn't understand the EAPI.
The order of processing for a package manager would be:

1. Scan for files named *.ebuild.
2. Scan the nth line inside to obtain the EAPI.
3. Take further action in accordance with the EAPI - possibly including
obtaining the package name/version from the filename, or maybe somewhere
else entirely.



* Needs more accesses to cache as now you don't have to load older
versions if the latest is not masked


Why wouldn't you cache every version of a package with its EAPI for
reference? I don't follow why this needs more cache hits. However,
even if you had to hit the cache more often I don't see why a cache
lookup would be expensive. Isn't it stored in a sensible format for
rapid random access?


My preference is obviously for embedding the EAPI inside the file in
some manner. My second preference would be for only changing the file
extension on rare occasions that are individually approved by the
Council when things need to change dramatically, as opposed to any time
the EAPI changes.
 
Old 02-25-2009, 01:40 AM
Jeremy Olexa
 
Default Collecting opinions about GLEP 55 and alternatives

Petteri Räty wrote:

Let's try something new. I would like to get opinions from as many
people as possible about GLEP 55 and alternatives listed here in order
to get some idea what the general developer pool thinks. Everyone is
only allowed to post a single reply to this thread in order to make it
easy to read through. The existing thread should be used for actual
discussion about the GLEP and the alternatives. This should be a useful
experiment to see if we can control ourselves

My notes so far:

1) Status quo
- does not allow changing inherit
- bash version in global scope
- global scope in general is quite locked down

2) EAPI in file extension
- Allows changing global scope and the internal format of the ebuild
a) .ebuild-<eapi>
- ignored by current Portage
b) .<eapi>.ebuild
- current Portage does not work with this
c) .<eapi>.<new extension>
- ignored by current Portage

3) EAPI in locked down place in the ebuild
- Allows changing global scope
- EAPI can't be changed in an existing ebuild so the PM can trust
the value in the cache
- Does not allow changing versioning rules unless version becomes a
normal metadata variable
* Needs more accesses to cache as now you don't have to load older
versions if the latest is not masked
a) <new extension>
b) new subdirectory like ebuilds/
- we could drop extension all together so don't have to argue about
it any more
- more directory reads to get the list of ebuilds in a repository
c) .ebuild in current directory
- needs one year wait

Regards,
Petteri



Thanks for gathering input from the dev community. I do not wish to
respond to the monster thread (and won't).


Personally, I don't need the flexibility that glep55 provides for *my*
ebuilds. The current scheme doesn't bother me. And actually, after doing
some testing, I found that at least one of that packages/projects that I
am involved in will need updating every time the extension changes (or
some more broad change - I don't have time to investigate too much tbh).
So, I would prefer that the file extension did not change [much/every
eapi]. However, I can roll with the punches if it truely is needed. I
also understand that some change is good in the long run even if it has
some upfront cost to it.


However, in case that this discussion gets deferred until later, I would
like to express that the Council should "request" (not demand) that
portage adds support for the leading 2 ideas that result from the
current discussion. This will allow us to not wait even longer when we
are having this discussion in 2010 (hypothetically).


Thanks for listening, Petteri.
-Jeremy
 
Old 02-25-2009, 02:53 AM
Dawid Węgliński
 
Default Collecting opinions about GLEP 55 and alternatives

On Tuesday 24 of February 2009 23:21:23 Petteri Räty wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a useful
> experiment to see if we can control ourselves
>
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

All of this are ok for me, though the first shot is my preffered one since
it's the most human readable and the rest would be mostly seen as the package
version.

>
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>

I don't see this as the best solution.

> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository

Nah. Scanning portage tree in this place would be more painful than it's
currently.

> c) .ebuild in current directory
> - needs one year wait
>
> Regards,
> Petteri
 
Old 02-25-2009, 03:32 AM
Alistair Bush
 
Default Collecting opinions about GLEP 55 and alternatives

Petteri Räty wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a useful
> experiment to see if we can control ourselves
>

Thank you Petteri. I knew there was a reason I voted for you.

>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage

a) then c). I personally think b) is a bad idea that will just slow the
implementation of this even more.

>
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait

If it really comes to it b)? Tho it leaves a bad taste in my mouth.

>
> Regards,
> Petteri
>
 
Old 02-25-2009, 05:46 AM
Alec Warner
 
Default Collecting opinions about GLEP 55 and alternatives

> On Tue, Feb 24, 2009 at 2:21 PM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks. Everyone is
> only allowed to post a single reply to this thread in order to make it
> easy to read through. The existing thread should be used for actual
> discussion about the GLEP and the alternatives. This should be a useful
> experiment to see if we can control ourselves
>
> My notes so far:
>
> 1) Status quo
> - does not allow changing inherit
> - bash version in global scope
> - global scope in general is quite locked down
>
> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage
> b) .<eapi>.ebuild
> - current Portage does not work with this
> c) .<eapi>.<new extension>
> - ignored by current Portage
>
> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache
> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable
> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked
> a) <new extension>
> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository
> c) .ebuild in current directory
> - needs one year wait

I'm adding stuff to this; but its in my copy of glep-55.txt which I
will probably send out later. I basically see this as a mix of
options and requirements and thats how I would expect the council to
make their decision.
For instance; if we don't care about backwards compatibility with
older managers than we can enable a number of other solutions that
would otherwise be excluded. If we want to be able to swap versions
of bash as a requirement; that automatically excludes specific
solutions that don't handle that case. So in my rewrite of glep55 I'm
attempting to make a list similar to yours and try to convey what
requirements are togglable for each thing. In the end I expect the
council to:

- Choose requirements that make the most sense for Gentoo.
- Look at the solutions that are left that meet said requirements and pick one.

dev.gentoo.org/~antarus/projects/gleps/glep-0055.html for the updated GLEP.

-A

>
> Regards,
> Petteri
>
>
 
Old 02-25-2009, 05:49 AM
Jeroen Roovers
 
Default Collecting opinions about GLEP 55 and alternatives

On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@gentoo.org> wrote:

> Let's try something new. I would like to get opinions [...]

A multitude of leaves on every branch of the tree. That could be a
multiple of the current tree size - maybe talk to infra about this.

It's also a multitude of complexity - as an arch security liaison, I
get to see how difficult it is already to figure out which revision to
test and mark, and figuring out why a certain revision isn't ready yet
is tantamount to figuring out what EAPI=foo actually means.

As an ebuild developer I get to see how difficult it is to figure out
which EAPI is ready enough to write ebuilds for - Changing filename
extensions is to me like a Windows 95 way of opening a file and it
doesn't at all tell me what I can and cannot put into that file.

Either as an arch, or as ebuild dev pur sang, I don't care about EAPIs
that much until I want to use a new feature - I don't want to maintain
EAPI=N branches of testing and stabling systems to test stuff either
before it's published or when it's time for stabilisation. Stamping
EAPIs down in filename extensions is just another way to point out the
cruft.

As a bug wrangler, it doesn't solve current problems of stale overlays
with too novel or too old ebuilds.

To users, it doesn't matter at all - which seems to bring about the
question of the use case everyone's clamouring for. What developers
will benefit this at all, how large are the branches this will affect,
how many developers will have to rewrite tools, and so on?


Kind regards,
jer
 
Old 02-25-2009, 05:53 AM
Ulrich Mueller
 
Default Collecting opinions about GLEP 55 and alternatives

>>>>> On Wed, 25 Feb 2009, Petteri Räty wrote:

> Let's try something new. I would like to get opinions from as many
> people as possible about GLEP 55 and alternatives listed here in order
> to get some idea what the general developer pool thinks.

I've already commented on this in December 2007 [1], and my opinion
hasn't changed.

> 1) Status quo
> 2) EAPI in file extension
> 3) EAPI in locked down place in the ebuild
> a) <new extension>
> b) new subdirectory like ebuilds/
> c) .ebuild in current directory

Acceptable for me would be 1) and 3c).

> - needs one year wait

Please state more precisely, what events would mark the beginning and
end of this time period?

Ulrich

[1] <http://archives.gentoo.org/gentoo-dev/msg_81b3eeb61186874caa291b66e728348c.xml>
 
Old 02-25-2009, 07:16 AM
Alexis Ballier
 
Default Collecting opinions about GLEP 55 and alternatives

I have no strong opinion about this.

> 2) EAPI in file extension
> - Allows changing global scope and the internal format of the ebuild
> a) .ebuild-<eapi>
> - ignored by current Portage

simple, straightforward but ugly

> b) .<eapi>.ebuild
> - current Portage does not work with this

this only has disadvantages in front of a)

> c) .<eapi>.<new extension>
> - ignored by current Portage

same as a) but maybe less ugly

> 3) EAPI in locked down place in the ebuild
> - Allows changing global scope
> - EAPI can't be changed in an existing ebuild so the PM can trust
> the value in the cache

This doesn't need a locked down place, just some strict way of setting
it, like at most one EAPI="constant_string_without_space" so that grep
& friends can catch it.

> - Does not allow changing versioning rules unless version becomes a
> normal metadata variable

I'm not entirely sure about this and would need some real
example/argument in order to be convinced

> * Needs more accesses to cache as now you don't have to load older
> versions if the latest is not masked

true but this "more" would need to be measured and opposed to the
number of metadata loads in a dep resolution procedure.

> a) <new extension>

doesn't have the one year wait drawback and doesn't mess with pm
implementation details (eapi) with package names that shall represent
upstream ones.

> b) new subdirectory like ebuilds/
> - we could drop extension all together so don't have to argue about
> it any more
> - more directory reads to get the list of ebuilds in a repository

I see no advantage there vs 3.a)

> c) .ebuild in current directory
> - needs one year wait

That could have been done one year ago and would be done now; I think
it's still fine now because I don't expect major behavior changes in
the ebuild format within one year.

To summarize, I would retain 3.a as best solution, having the "usable
right now" advantage of current glep55 and keeping the ebuild's file
names (more or less) consistent with upstream ones.

Alexis.
 

Thread Tools




All times are GMT. The time now is 01:01 AM.

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