Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
(trying to have people understand the idea, not to discuss in this thread) On Fri, 2009-03-13 at 06:18 +1300, Alistair Bush wrote: As long as we want/have to support PMs lacking EAPI detection in '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI to an '*.ebuild' must be hackish. So we can try to find the least ugly hack, or we need to change the extension. inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'. How would the 4.eclass determine whether the package manager actually supports the eapi? inherit is a function remember so any special parsing will not change the fact the the inherit function will be called. Will then need to determine whether there is actually a PM that doesn't support the eclasses EAPI and then die. The most important point here I thought everyone is aware of: inherit() is a function provided *by* PM - or am I wrong here? So it already *knows* to handle the 'eapi' argument as special when the PM is compliant, to not read *any* eclass for this one inherit-call when the ebuild gets sourced (assuming selected eapi specifies to shell-source the ebuild). And non-compliant PMs would mask the ebuild 'by corruption', because of either missing or globalscope-dying eapi.eclass, whatever can be made look more obvious to the user. What are the implications of calling inherit multiple times within an ebuild? A compliant PM does allow this if the selected eapi specifies to inherit eclasses, a non-compliant PM will not come to a subsequent inherit call after 'inherit eapi'. Im sorry, but this just sounds like a HACK, and a hacky hack at that. Agreed (see above). Again - the only reason for this idea is to eventually allow for keeping the '.ebuild' extension, because EAPI 0 does not allow for specifying *any* eapi at all. It just forces PM to provide inherit() as the only PM-defined global-scope function. So whatever we try, specifying an eapi inside an .ebuild *without* changing the extension *will* be a hack, just more ore less ugly. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Michael Haubenwallner wrote: Hi, Reminder (for myself): As long as we want/have to support PMs lacking EAPI detection in '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI to an '*.ebuild' must be hackish. So we can try to find the least ugly hack, or we need to change the extension. So just another idea, based on the eapi() function one: As inherit() is the only(?) global function provided by old PMs, the first non-commentary/non-blank line in '*.ebuild' could read: inherit eapi Compliant PMs identify 'eapi' as a special eclass name (with or without sourcing the ebuild), to know that this ebuild specifies an EAPI. For non-compliant PMs, we need to provide an 'eapi.eclass', which just spits some 'your PM lacks EAPI support' message and causes the PM to mask this ebuild 'by corruption' or the like. Or - what are old PM's messages when an eclass is missing? Eventually, this line also could finally specify the EAPI and read: inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'. How would the 4.eclass determine whether the package manager actually supports the eapi? inherit is a function remember so any special parsing will not change the fact the the inherit function will be called. Will then need to determine whether there is actually a PM that doesn't support the eclasses EAPI and then die. What are the implications of calling inherit multiple times within an ebuild? Im sorry, but this just sounds like a HACK, and a hacky hack at that. /haubi/
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Hi, Reminder (for myself): As long as we want/have to support PMs lacking EAPI detection in '*.ebuild' to mask ebuilds with unknown EAPI, each approach to add EAPI to an '*.ebuild' must be hackish. So we can try to find the least ugly hack, or we need to change the extension. So just another idea, based on the eapi() function one: As inherit() is the only(?) global function provided by old PMs, the first non-commentary/non-blank line in '*.ebuild' could read: inherit eapi Compliant PMs identify 'eapi' as a special eclass name (with or without sourcing the ebuild), to know that this ebuild specifies an EAPI. For non-compliant PMs, we need to provide an 'eapi.eclass', which just spits some 'your PM lacks EAPI support' message and causes the PM to mask this ebuild 'by corruption' or the like. Or - what are old PM's messages when an eclass is missing? Eventually, this line also could finally specify the EAPI and read: inherit eapi 4 Because non-compliant PM's already quit because of (missing or dying) eapi.eclass, there is no need to have a '4.eclass'. /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Hello all, Here are my comments, opinions, and a recommendation regarding GLEP 55 and similar proposals. I've put in 1) A) and a) numbering to differentiate the various lists. Though perhaps long winded, at least check out the Recommendation below. The idea of sticking EAPI in metadata.xml was opposed because of XML overhead, and it's a general purpose file, whereas this would force it to have versioned info. Makes sense to me. Though that was one of the ideas I was toying with because the EAPI really is metadata. = Extension = I don't like the idea of changing the extension because (in part summarizing what some others have said): 1) inconsistency is not good (rh/fedora has always been .rpm, debian has had .deb, gentoo has .ebuild) That's also why we prefer tabs over spaces and ordering the variables uniformly (at least on sunrise). It's a consistency issue. 2) If you change the extension, it becomes technically more difficult to prevent multiple versions of the same package, thus users probably will be required to start specifieing an EAPI when they want to merge a package, because several devs, perhaps on overlays, will start providing multiple versions of ebuilds in different EAPI. 3) #2 brings GLSA into play - Changes may have to be made in packages implementing a variety of eapis creating a greater burden to see what the difference is between these different ebuilds. 4) If portage does enforce the single eapi per version, that creates an even bigger problem for other package managers which was a problem that this GLEP was trying to address, but ends up making smooth interop even more difficult. Some PMS will support multiple EAPIs and others will say no... Overlays... 5) Version bumps are more difficult as you have to worry about the eapi in the file name 6) If GLEP 55 goes in without GLEP 60, you may need to add a new key in the Manifest for each new EAPI: EBUILD-1 EBUILD-2 EAPI-2-EBUILD... (or something like that) As it is it's just EBUILD. If/when GLEP 60 goes in as well, then you have the issue of, we changed the name - it's no longer an ebuild, but the manifest says it is which might be a tad confusing (and inconsistent) = In Ebuild = The idea of leaving EAPI defined in the ebuild has the following setbacks: A) sourcing the ebuild to discover the EAPI enforces a strict global part, which prevents significant changes to inherit amongst other things B) It could break as we migrate to newer versions of bash or perhaps ebuilds or equivalents that might be in another language (who knows) C) Having a spot locked down in an ebuild to search for EAPI brings a migration drawback, as current ebuilds have something else on line 4 or line 5 or whatever, and a potentially erroneous value could be returned for EAPI D) Sourcing the ebuild twice brings a lot of overhead significantly slowing an already (many times) slow process (especially when you imagine KDE and other packages that take a while to compile - 6 seconds extra for each package - *shiver*). And it's ugly to have to do it twice. E) EAPI really is metadata and doesn't should be accessible before sourcing the ebuild. = Recommendation = OK. Now for a slightly different solution, or a twist on the other solutions if you will: Stick EAPI info in the Manifest. The Manifest stores metadata info about the ebuilds for security and validation purposes, why not add a string that determines which eapi to use? This then would be generated every time someone did an ebuild foo-1.0.ebuild digest. To specify the eapi version, the developer would specify, as is now, EAPI=bla in his ebuild, and grep or similar would be used to extract this when the digest is created. The above mentioned points compare with this solution (as I see it) as follows: -1) Preserves .ebuild allowing for changes if a move were ever made to some other format (who knows: python, or some-cool-new-script-that-beats-bash-by-a-long-shot) -2) Does not change the extension -3) Ditto -4) Ditto -5) Version bumps might take a fractoin longer, as an additional grep is added to the digest process... but arch maintainers shouldn't have a problem with that. (I'm not an arch maintainer, mind you. I'm not even @g.o) -6) This takes care of any Manifest issue, because eapi'll be defined to start off with in the Manifest in a uniform manner -A) No need to source the ebuild twice, just grab the variable from the manifest in the normal execution of digest verification. However if the digest is wrong, or the Manifest doesn't exist or whatever, that is an error and error handling will need to be introduced to grep the EAPI at this point if regenerating the digest is needed/requested -B) A new EAPI would be introduced for such new versions of bash and if there were other formats (as in, not bash) they really should get their own extension anyway, but we need some uniform way to grep it and grab the info, or if it can't be found assume that it's EAPI 0 -C) It wouldn't have
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Thanks Petteri, 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down lets move on! 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 2 a) and 2 c) are fine by me. 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 no thanks. Regards, Petteri regards Thilo
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
EAPI inside ebuild is the best solution. If we really have to put it inside filename, keep it out of extension, like 2) b) suggests. -- Peter.
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
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 the solution that solves most problems. Going with something else is just a way of doing it wrong for the sake of it. - ferdy pgpfhEMRKGC35.pgp Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: 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 I have been thinking about this specific option. I will admit I don't know if this has already been noted, but would this create the possibility of multiple ebuilds with the same $C/$P-$PV? Currently the filesystem enforces the uniqueness of that tuple, will that uniqueness be allowed to lapse? (i.e. allow multiple ebuilds for the same $C/$P-$PV with different EAPIs?) If not, how is anyone proposing to enforce the uniqueness here? Just a silly thought... RobbieAB
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Sat, 28 Feb 2009 19:39:36 + Robert Bridge rob...@robbieab.com wrote: I have been thinking about this specific option. I will admit I don't know if this has already been noted, but would this create the possibility of multiple ebuilds with the same $C/$P-$PV? GLEP 55 forbids it. Note that it's already possible to have multiple equal versions of the same thing (1.0_alpha0 equals 01.0_alpha-r0), and it's already illegal. None of this is altered by any of the proposals. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Kumba wrote: I was talking to Alec last night in -dev (yes, I'm still alive), and I tossed out the idea of using metadata.xml instead of mangling the ebuild filename or even sticking it as the first line in the ebuild (as a hashbang or something gentoo-specific, for example). Fleshing out more (And to solicit more thought on this idea -- insane?). Using mips-sources as an example: # ls -l /usr/portage/sys-kernel/mips-sources/*.ebuild total 116K -rw-r--r-- 1 root root 19K Jan 9 04:10 mips-sources-2.6.20.18.ebuild -rw-r--r-- 1 root root 18K Jan 9 04:10 mips-sources-2.6.27.10.ebuild -rw-r--r-- 1 root root 18K Feb 23 16:43 mips-sources-2.6.28.7.ebuild Would, to specify them as EAPI=2 in metadata.xml, be encoded as (just an example -- suggest other formats): eapi pv=2.6.20.18 ver=2 / eapi pv=2.6.27.10 ver=2 / eapi pv=2.6.28.7 ver=2 / pv = specifies the package version ver = eapi version. Better names for these values? Suggest! I didn't want to re-use 'api' or anything. Maybe pms pv=2.6.28.7 eapi=2 / ? Anyways, after commiting to gentoo-x86 CVS, a backend script, similar to or the same as whatever parses out the use tags will run and extract this data, and update /usr/portage/profiles/eapi.list (example name). /usr/portage/profiles/eapi.list will resemble something like this: sys-kernel/mips-sources-2.6.20.18:2 sys-kernel/mips-sources-2.6.27.10:2 sys-kernel/mips-sources-2.6.28.7:2 Upon installing the package by whatever package manager (portage is my example), it will process this eapi.list, much like it does use.desc and use.local.desc, and therefore know all it needs to know, then it can source the ebuild and use whatever logic it needs to follow that specific EAPI. That is if my assumption is correct that the usr.desc/use.local.desc stuff is parsed prior to the ebuild itself being sourced. If not, well, I dunno then. I'm guessing here. The pros of this that I can see: - No changes to the current filename structure. Things stay the name, CVS history is retained because existing files aren't renamed (we're not on git just yet). - No special markers, comments, or bash vars inside the ebuild. Covers some of the other cons that were presented. - Older package managers won't read eapi.list, and can resume their default behavior of EAPI=0. Allows backwards compatibility. - Newer package managers will assume a non-entry in eapi.list to equal EAPI=0, so there won't be a big rush to update every package/metadata in the tree. Allows for slow, controlled adoption. Cons that I can see: - metadata.xml gets updated more frequently because specific versions can get cited (workaround idea, see below) - Backend has to do extra work (minimal? Can infra comment on the feasibility of this?) I'm suggesting this mostly because both ideas of embedding the EAPI value in the filename and inside the ebuild seem like ugly workarounds. Others are also noting other problems with both of these approaches. EAPI also feels more like a metadata-type thing anyways. I mean, if we're already storing local USE flags in it, why not EAPI stuff? I'm a tad behind on the whole discussion, I know, but why not toss the idea out there. Some other thoughts on the first con, of metadata being updated more frequently -- we allow the use of wildcards: eapi pv=* ver=2 / Would mark every ebuild in the directory for a given EAPI value (EAPI=2 in this case) eapi pv=2.6* ver=1 / Marks every ebuild version lower than 2.6 as EAPI=1. Basically, the wildcard modifiers Portage currently understands would apply. Or we could limit it to a subset of these wildcards (say, *, , , =, and =). Obviously, tools like repoman would need to be able to read metadata as well (can it? I don't know) and make sure that the versions specified in the 'pv' value exist in the directory before commit. Either by specific value or by expanding the wildcard notation and then cross-referencing the files listed in the directory and with CVS/git/whatever. But to be honest, none of the ideas, even my own, seems like the best idea. I think of mine as less intrusive to the tree and less visible to the end users and the package managers, but maybe there's other options not thought of yet? -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tue, Feb 24, 2009 at 5:21 PM, Petteri Räty betelge...@gentoo.org wrote: 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 don't see the point of some of these... a shorter extension would be nice but not really necessary. .eapi.ebuild so like .2.ebuild 'cause that'd work great? smith-1.3.6.2.ebuild better yet vanilla-sources-2.6.28.2.2.ebuild yeah I can see that working out... no it wouldn't or maybe smith-1.3.6.eapi-2.ebuild just too long here's an idea, perhaps not a great one... but perhaps it'll make someone else think... how about this on the first line # eapi-2 and instead of sourcing it, have portage match it with a regex first, figure out the eapi, then source it. I don't know if I really like like what I'm proposing, but I don't see anything else that looks good. -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
My 2¢ : Keep the EAPI inside the ebuild itself. On the first line, on the fifth line, as an argument with the shebang, as a comment, as a variable, as a function call, ... I really don't care what it looks like, as long as it's inside the ebuild. Cheers, Rémi
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@gentoo.org wrote: 3) EAPI in locked down place in the ebuild There's a less extreme variant on this that's slightly cleaner, and with appropriate weaseling is also less messy. Simply add the following very carefully worded additional requirement for future EAPIs, and retroactively impose it upon current ones: If EAPI is to be set, it must be set strictly before any global scope command or package manager defined function is called. Once set, EAPI must not be set to a different value. Then, the migration path is as follows: * Fix existing violations (including ones in overlays). Wait a while until everyone's synced. * Get package managers to make use of these stricter requirements to avoid barfing ickily when using things with future EAPIs with different global scope rules. * Wait a year. New EAPIs can come out in the mean time, but they can't change global scope behaviour. * Use that year to migrate to the key=value cache format with a second, package-manager-only versioned variable that lets package managers check cache validity even for unsupported EAPIs so long as there aren't any cache validation rule changes. * Change global scope behaviour in new EAPIs at will, but not versioning rules. Note that this is functionally equivalent to Brian's eapi as a function proposal, but much less messy. It's also as powerful for the package manager as fixed-position, but less inflexible. So if you must go with something other than GLEP 55, along with all the restrictions and mess that doing so imposes, this is the one to pick... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Thu, 26 Feb 2009 18:07:32 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: There's a less extreme variant on this that's slightly cleaner, and with appropriate weaseling is also less messy. Simply add the following very carefully worded additional requirement for future EAPIs, and retroactively impose it upon current ones: If EAPI is to be set, it must be set strictly before any global scope command or package manager defined function is called. Once set, EAPI must not be set to a different value. ...not quite weasely enough. Also needs: and before any package manager defined variables are used or package manager set shell behaviour is relied upon. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Thu, Feb 26, 2009 at 11:50 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Thu, 26 Feb 2009 18:07:32 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: There's a less extreme variant on this that's slightly cleaner, and with appropriate weaseling is also less messy. Simply add the following very carefully worded additional requirement for future EAPIs, and retroactively impose it upon current ones: If EAPI is to be set, it must be set strictly before any global scope command or package manager defined function is called. Once set, EAPI must not be set to a different value. ...not quite weasely enough. Also needs: and before any package manager defined variables are used or package manager set shell behaviour is relied upon. Is the following a stricter subset of your wording? -- EAPI must be set in an ebuild as the first non-comment line, and thereafter must not be set to a different value I'm asking because it would be simpler for users and devs to understand, even if it is a subset. -- ~Nirbheek Chauhan
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Fri, 27 Feb 2009 00:17:36 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
Is the following a stricter subset of your wording? --
EAPI must be set in an ebuild as the first non-comment line, and
thereafter must not be set to a different value
No. With your wording, the following are legal:
EAPI=$(echo 1 )
EAPI=${PV}
EAPI=$( a=() ; a+=3 ; echo ${a[0]} )
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Fri, Feb 27, 2009 at 12:26 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Fri, 27 Feb 2009 00:17:36 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
Is the following a stricter subset of your wording? --
EAPI must be set in an ebuild as the first non-comment line, and
thereafter must not be set to a different value
No. With your wording, the following are legal:
EAPI=$(echo 1 )
EAPI=${PV}
EAPI=$( a=() ; a+=3 ; echo ${a[0]} )
Ah, I thought I might be missing something. Then how about:
EAPI must be set in an ebuild as the first non-comment line, such
that bash does not perform any expansions during the assignment, and
thereafter must not be set to a different value
of course, this is entirely documentation-oriented, and might be
bike-sheddery :)
--
~Nirbheek Chauhan
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Fri, 27 Feb 2009 00:46:04 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: Ah, I thought I might be missing something. Then how about: EAPI must be set in an ebuild as the first non-comment line, such that bash does not perform any expansions during the assignment, and thereafter must not be set to a different value Close, but no banana. You've also got to specify that any syntax used up to and including that line has to be bash-3 legal. The problem is... If bash-5 introduces multi-line comments or a new assignment syntax, your version doesn't forbid: #* Copyright etc more multiline stuff *# let EAPI = 3 Unfortunately, we have to care about these things when doing the formal spec... There're developers who'll pull all kinds of insane crap in the tree... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] 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. signature.asc Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Hi! My preference, most wanted to least wanted: - inside the ebuild If it's not too much pain. Yes, that is a very subjective metric and it's what a large amount of flames has been about. - in the filename, but not as a tail eg: foo-2.3.4-r2+9.build yes, alternate separators might be better. I like .build very much, though. What does the e in ebuild stand for anyway? - in the filename, as a tail eg: foo-2.3.4.ebuild-9 I don't like this much, but it's better than never having EAPI versioning. Regards, Tobias -- printk(Cool stuff's happening!\n) linux-2.4.3/fs/jffs/intrep.c
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@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. [...] I dislike GLEP 55 aesthetically, but I see no other way to move out of this deadlock where we can't use new bash-features till years have passed. So unless someone suggests a solution that allows us to have EAPI as part of the ebuild without having to wait till hell freezes over, I'm behind GLEP 55 as the least-bad solution. /loki_val
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 2009-02-25 at 00:21 +0200, Petteri Räty wrote: get opinions [..] to get some idea what the general developer pool thinks. only allowed to post a single reply to this thread Thank you for that, I usually don't follow long threads, so apologies if things have been discussed already. Basically, I'm all for having GLEP55 as good as possible in favour of as soon as possible before implementation, even if it fits my thoughts quite good already (see below). 2) EAPI in file extension IMO, this should define *how* to read the *final* EAPI from the ebuild. The *how* does not necessarily mean to /source/ the ebuild, so the terms pre-source EAPI and post-source EAPI IMHO are too strongly focussing on (bash) source $EBUILD when used in a generic GLEP. Eventually, the pre-source EAPI could be called major EAPI, and the post-source EAPI could be called major.minor EAPI (see below). The EAPI in file extension also should define the filename-part of the versioning rules. a) .ebuild-eapi c) .eapi.new extension - ignored by current Portage b) .eapi.ebuild - current Portage does not work with this ignored by current portage is an important point for me to *theorethically* guarantee for a possible upgrade path even over long time. 3) EAPI in locked down place in the ebuild This lock down should be done by EAPI in file extension above. lock down can mean any of: post-source (real bash-source), self-parse (grep?), fixed-byte/line-offset, ... My thoughts are to split EAPI into several levels (rename them however you like): entry-point: Specifies how to read the filename-scope EAPI. filename-scope EAPI: Think as major EAPI. Specifies the filename-part of versioning rules. Specifies how to read the global-scope EAPI (can, but eventually should not require bash-sourcing the ebuild). May allow to not define minor, assuming $major.0.0 then. global-scope EAPI: Think as $major.minor EAPI. May specify how to define additional versioning rules. Specifies how to define metadata information. Specifies which metadata information is required/optional/cached/... Specifies how to utilize external resources (eclasses). Specifies which/how actions can/must be defined (pkg_*, src_* functions). Specifies how to read the local-scope EAPI. May allow to not define micro, assuming $major.$minor.0 then. May disallow a local-scope EAPI, specifies it instead. local-scope EAPI: Think as $major.$minor.micro EAPI. Specifies which PM-functions are available for use in actions (fex 'doman' inside src_install). May be specified as part of minor EAPI. Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: 3) EAPI in locked down place in the ebuild c) .ebuild in current directory - needs one year wait I'm all for 1 or 3c, because we're not in any rush. I don't see why there's such an immediate need to make as drastic changes as are being suggested for GLEP-55, simply to allow for the possibility of future unknown ebuild mechanisms (like ebuilds not being bash scripts). If ebuilds change significantly from their current form, then and only then, would it be a good time to change the ebuild suffixes. I don't want to get an attachment from bugzilla and find I have to try four different file extensions because whilst the package and version were obvious from the bug, the eapi number wasn't. I also don't want to run into a situation where this package manager supports kdebuilds, whilst that package manager supports gnomebuilds, and a third one supports xfcebuilds. That's just recreating the browser wars, and will leave us with the likes of IE6. I'd be relatively happy with a shebang that specifies the parser or passes the ebuild version, as long as it was standardized, linear and supported by all the PMs (ie, some rogue PM can't suddenly start allowing a myeapi that only it can build)... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmlKQEACgkQu7rWomwgFXoRFACdHfDHuHhj7ojsQV5FvF+rRpRT PgQAoKTq6iAmNLC50a97JHrQghRZK6O0 =ELuP -END PGP SIGNATURE-
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty betelge...@gentoo.org wrote: 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage c) .eapi.new extension - ignored by current Portage Any of the above are fine with me, there is a demonstrated need for this to introduce changes that current portage could not handle. 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 3.a is just like glep-55, except that the filename extension doesn't change all the time. I like that this will have the benefits of glep-55 plus the benefits of making happy the people who don't want the EAPI in the filename or the extension to change very often. This will effectively change a single EAPI number into a major/minor pair. The major part (the extension name) would only ever change when a major feature is introduced that breaks the current portage rules. The internal EAPI, specified however we like in the major format specification, could be in a fixed location or otherwise easily parseable. Then small changes would alter this minor/internal EAPI value. -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm/vim)
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: 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 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). pros: - global scope changes can occur (inherit mechanism changes included). - expanding on the first, auto inherits (pkg level) are possible- effectively when eapi gets invoked the manager is in control and can do whatever is desired setting up the env wise. - bash version requirements can be leveled (bash parses as it goes, meaning that essentially it won't parse what follows 'eapi 2' till that command statement finishes) - fits w/ the existing semantics nicely enough. cons: - mangling the version rules for pkgs still isn't possible; no -scm. Arguable if -scm is even desired, but being explicit about it not covering this. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Personally, if g54 is ixnayed #4 I tend to think is the best option out there- if g54 is forced in, g55 (or at least something that adjusts the extension to make it invisible to current managers) is required. Commentary? Tend to think #4 is the most aesthetically pleasing to folk, but who knows... ~harring pgpoX8H8NE7jK.pgp Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tuesday 24 February 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. Thanks for opening a spot to voice our opinions within reasonable limits and without deadlocked discussions. To make it brief, I'd very much prefer 3c[0] for the reasons provided by others before: - From what I can see, it provides for all requirements set out by g55. - There is a backwards-compatible way to implement it. - It does not expose any more internal metadata than current ebuilds do. - I see no rush to implement new EAPI features that require drastic changes enabled by 1*. - It provides a constant face for Gentoo, aka we're the guys and gals using the .ebuild format. Robert [0] Although not with a fixed line limit, but with a strict way to find it, i.e. the first occurence of #?\s*EAPI=[']?([a-zA-Z0-9._]+)[']? or similar. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote: 1) Status quo - does not allow changing inherit - bash version in global scope - global scope in general is quite locked down Yuck, I want per-package eclasses and all those other goodies. 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 2a please, though .ebuild.eapi would be fine as well. My reasons are mostly contained in Antarus' glep revision, and the fact that there have been no real valid(IMO) objections. 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 These are all ugly.(c is the worst). Oh, And I certainly hope this is not Democracy(you know what they say, democracy is two wolves and a sheep deciding who to have for dinner) Looking forward to the council meeting, where there will *hopefully* be a decision. Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpFU0kxFHMxR.pgp Description: PGP signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Ulrich Mueller wrote: 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). I have also stated my opinion before. But I agree with Ulrich. -Joe
Re: [gentoo-dev] 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 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 Leave EAPI inside the ebuild. That's where I want to find it. Oh, and as others have mentioned, CVS sucks for file renaming and versions. Yet another reason to leave it inside the ebuild. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Brian Harring wrote: 4) eapi as a function; instead of EAPI=1, do eapi 1, required as the first statement (simplest way). pros: - global scope changes can occur (inherit mechanism changes included). - expanding on the first, auto inherits (pkg level) are possible- effectively when eapi gets invoked the manager is in control and can do whatever is desired setting up the env wise. - bash version requirements can be leveled (bash parses as it goes, meaning that essentially it won't parse what follows 'eapi 2' till that command statement finishes) - fits w/ the existing semantics nicely enough. cons: - mangling the version rules for pkgs still isn't possible; no -scm. Arguable if -scm is even desired, but being explicit about it not covering this. - transition is slightly icky; basically one of the following is required- a) for EAPI=2, do 'eapi 3 || die upgrade your manager'. Reason for this is that current managers obviously lack an eapi function, to make managers available *now* blow up the || die is required. This solution can be deployed now, no transition required although at some point stating eapi is required retroactively for all eapis would be wise to eliminate the need for the || die (cut support basically for old managers) b) bashrc trickery, defines an eapi if it's unset. Said eapi function exports EAPI=$1, optionally triggering a die if the eapi isn't 0,1,2 (since any later eapi would require a manager upgrade which would also have the eapi function). Personally, if g54 is ixnayed #4 I tend to think is the best option out there- if g54 is forced in, g55 (or at least something that adjusts the extension to make it invisible to current managers) is required. Commentary? Tend to think #4 is the most aesthetically pleasing to folk, but who knows... ~harring I really like this idea, but nobody else seems to have commented on it. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux DeveloperCatalyst/Genkernel + Release Engineering Lead
Re: [gentoo-dev] 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 Another option which I haven't seen mentioned here yet would be to just specify that the method of finding the EAPI depends on the file extension. Then, anything with a .ebuild extension can be sourced with bash to find the EAPI, and ebuild formats incompatible with that could use another file extension. This would work with current package managers, while still providing a mechanism for incompatible format changes in the future. It's also aesthetically nicer than current proposals, since the file extension would indicate something about the contents of the file. Or, to put it another way, this would formalize the difference between the ebuild format (which is currently bash throughout the tree), and the EAPI. I don't think anybody would oppose a file extension change for a format change, as opposed to an EAPI change. --Ravi
Re: [gentoo-dev] 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 :) I was talking to Alec last night in -dev (yes, I'm still alive), and I tossed out the idea of using metadata.xml instead of mangling the ebuild filename or even sticking it as the first line in the ebuild (as a hashbang or something gentoo-specific, for example). It's nothing fully fleshed out, and I know parsing XML is about as much fun as sticking your tongue into a cross-cut paper shredder, but I figured why not toss it out there? Add a tag like this to metadata.xml eapi pv=2.6.28.7 version=1 / pv = Package Version (incl. revision if needed). v = EAPI version. Other variants: eapi version=1mips-sources-2.6.28.7/eapi eapi pv=2.6.28.71/eapi and such. This allows portage or whatever to associate the chosen/desired EAPI level with a given ebuild version in portage (so the above examples would match mips-sources-2.6.28.7.ebuild) I think there's some other magic going on after metadata is updated in portage, like the whole use.local.desc auto-updating. I figure something like this could also be implemented, maybe even in the same way whereby a backend script parses this out and create a /usr/portage/profiles/eapi.list file that links package revisions with the set eapi level. Then let the various package managers do whatever it is that they do to make use of this information. Call it random brainstorming. No idea on the pros cons -- I haven't even looked at g55 just yet. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 I don't want to stick with the status quo since being able to probe the EAPI without sourcing the ebuild is quite useful. Among other things, it allows the package manager to avoid the overhead of sourcing the ebuild in case neither the EAPI nor the cache format is understood, which solves a problem [1] discussed in the thread about adding DIGESTS data to the cache. 2) EAPI in file extension - Allows changing global scope and the internal format of the ebuild a) .ebuild-eapi - ignored by current Portage I'd prefer not to introduce an infinite series of file extensions. To me that just seems too unconventional. b) .eapi.ebuild - current Portage does not work with this c) .eapi.new extension - ignored by current Portage Either of these is fine with me. 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 think it's alright to change the EAPI in an existing ebuild. Since you can simply parse the EAPI instead of sourcing the ebuild, having a valid cache isn't so important. - Does not allow changing versioning rules unless version becomes a normal metadata variable As said by Richard [2], it's alright to change the version rules. Since you can simply parse the EAPI, it's not appreciably less accessible than if the EAPI is embedded in the file name. * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked Accessing the cache or parsing the EAPI is relatively inexpensive compared to sourcing the ebuild, so it's not really a problem. Again, once you can parse the EAPI, it's not appreciably less accessible then if the EAPI is embedded in the file name. a) new extension I think a new extension is preferable to a directory. 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 You really only need to wait in order to avoid things like warning messages about invalid name/version (if you want to do naming convention changes). If the name/version appear valid, the existing cache entries will prevent the ebuild from being sourced by existing versions of portage (as long as the timestamp of the cache entry matches the timestamp of the ebuild). [1] http://archives.gentoo.org/gentoo-dev/msg_d667a0dd748b2fefa5a5378000104974.xml [2] http://archives.gentoo.org/gentoo-dev/msg_bf3aa0199bb521b263b19b4997a0429c.xml - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmmKkoACgkQ/ejvha5XGaP+2gCfZvkKYypzKydZ+1+sShQkJKr3 ObAAoNr1r9E9eNRCAisahJyqcu6FDV3S =kj8B -END PGP SIGNATURE-
[gentoo-dev] Collecting opinions about GLEP 55 and alternatives
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 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@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) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] 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.
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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
Re: [gentoo-dev] 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
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Tue, Feb 24, 2009 at 2:21 PM, Petteri Räty betelge...@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
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
On Wed, 25 Feb 2009 00:21:23 +0200 Petteri Räty betelge...@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
Re: [gentoo-dev] 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
