Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
slot deps. And I think that's a valid usage.
1:
http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass
It's better (the only way...) to die in case an ebuild sets lower EAPI,
like kde4-functions.eclass does:
case ${EAPI} in
2) : ;;
*) die No way! EAPI older than 2 is not supported. ;;
esac
--
Peter.
signature.asc
Description: Эта часть сообщения подписана цифровой подписью
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Samstag, 28. Februar 2009, Peter Volkov wrote:
В Втр, 24/02/2009 в 16:14 +0200, Serkan Kaba пишет:
lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use
slot deps. And I think that's a valid usage.
1:
http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/luc
ene-contrib.eclass
It's better (the only way...) to die in case an ebuild sets lower EAPI,
like kde4-functions.eclass does:
case ${EAPI} in
2) : ;;
*) die No way! EAPI older than 2 is not supported. ;;
esac
I still dislike die in global scope, why not do it like autotools.eclass?
It does:
DEPEND=INCORRECT-WANT_AUTOCONF-SETTING-IN-EBUILD
Regards
Matthias
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Alec Warner antarus at gentoo.org writes: Somewhat ironically, had everyone been less stubborn last year when discussing this topic we could have embedded the EAPI in line X of the ebuild in 2008 and be using it now; instead of still discussing it. I don't expect new novel ideas out of this thread. I expect the council to defer it again because the arguments are the same as last time and last time they were not convincing enough. I would prefer if the council went one way or the other so that when we are arguing about this in 2010 we can at least say hey we have support in $PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we can just switch. We don't have to make the switch; I'm just saying we should add support to hedge our bets. Thoughts? Well I give up. There have been exactly zero technical arguments against GLEP 55 and plenty of rhetoric, but if that's enough to sway people then so be it. If we take EAPI extensions off the table, which of these would work the best (aka. gives people the warm fuzzies). - eapi in the file name, still ends in .ebuild -- no parsing needed -- doesn't allow version suffix additions/changes -- requires an initial wait period for PM's to implement support and be stabilized -- still makes some people grumpy/threaten to leave - eapi in the ebuild, on a predetermined line number -- error prone, restrictive -- doesn't require parsing -- doesn't allow version suffix additions/changes - eapi in the ebuild, anywhere -- what we have now -- currently requires sourcing the ebuild -- sourcing the ebuild requires knowing the EAPI -- doesn't allow version suffix additions/changes (actually, none of these do, so i'll stop repeating it) - eapi in the ebuild, before any other assignments/commands -- ie. if we hit inherit and no EAPI is defined, EAPI=0 -- restrictive (eapi must be a direct assignment, no conditionals, etc) -- no per category/PN eapi's or eapi's set in eclasses -- probably the next best solution (IMUO) - eapi in metadata somewhere else -- meh, i'll let the proponents of this argue for it please fill your arguments for or against, or fix whatever i have wrong. some other random ideas i've seen tossed around: - #!/bin/env eapi-parser - split EAPI into EAPI and some separate counter which would only be incremented on uncompatible changes to the ebuild format - change .ebuild to .eb - waffles (sorry, lunchtime)
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Tue, 24 Feb 2009 09:36:29 -0700 Joe Peterson lava...@gentoo.org wrote: 2) it makes sense to have these in the filename, but not internal meta-data For those of us who understand the process, it makes sense to have EAPI in the filename too. Which seems to be an enlightened few who... How did we manage before you graced us with your presence?! *humbly prostrates myself before this paragon of enlightenment* Robbie
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.02.24 16:48, Ciaran McCreesh wrote: [snip] PN and PV are metadata, same as EAPI. [snip] -- Ciaran McCreesh So we made a mistake with PN and PV and may compound it with EAPI. How long before we *must* have other pieces of information in the filename? When will the filename get so long as to become unwhieldy ? Lets fix it properly now since it will be much more painful to put an extendable solution in place later. It reminds me of other hacks in the history of the PC which we would do well not to repeat. e.g. the MSDOS Partition Table, the Extended Partition, the High Memory Area. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmkZAsACgkQTE4/y7nJvatrUwCgpEKpHAF0hdbkZIJavjwXtABT eXAAoPlWbQ0B4+F3YFPjrjCXHjuwS2m1 =r7kn -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 21:17:57 + Roy Bamford neddyseag...@gentoo.org wrote: PN and PV are metadata, same as EAPI. So we made a mistake with PN and PV and may compound it with EAPI. How long before we *must* have other pieces of information in the filename? Uh, never. When will the filename get so long as to become unwhieldy ? Uh, never. Lets fix it properly now since it will be much more painful to put an extendable solution in place later. 55 is the fix. It reminds me of other hacks in the history of the PC which we would do well not to repeat. e.g. the MSDOS Partition Table, the Extended Partition, the High Memory Area. Except that once we have EAPI in the file extension, we can change anything we want in arbitrary ways without having to worry about backwards compatibility, so we won't need silly hacks. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Tue, 24 Feb 2009 21:17:57 + Except that once we have EAPI in the file extension, we can change anything we want in arbitrary ways without having to worry about backwards compatibility, so we won't need silly hacks. Like the file name structure?
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.02.24 21:23, Ciaran McCreesh wrote: On Tue, 24 Feb 2009 21:17:57 + Roy Bamford neddyseag...@gentoo.org wrote: PN and PV are metadata, same as EAPI. So we made a mistake with PN and PV and may compound it with EAPI. How long before we *must* have other pieces of information in the filename? Uh, never. When will the filename get so long as to become unwhieldy ? Uh, never. [snip] Except that once we have EAPI in the file extension, we can change anything we want in arbitrary ways without having to worry about backwards compatibility, so we won't need silly hacks. -- Ciaran McCreesh Ciaran, Your response amounts to empty assertions. Never is a long time. It reminds me of a similar assertion that 640kB [of RAM] will be enough for anyone. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) iEYEARECAAYFAkmkcKkACgkQTE4/y7nJvaujMwCdES699P2BXc6VBRKfG4S9As4o CakAnAp8tsStf1NfKp1AEsGAQC8yxuoE =zCeb -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 22:11:47 + Roy Bamford neddyseag...@gentoo.org wrote: Except that once we have EAPI in the file extension, we can change anything we want in arbitrary ways without having to worry about backwards compatibility, so we won't need silly hacks. Your response amounts to empty assertions. Never is a long time. It reminds me of a similar assertion that 640kB [of RAM] will be enough for anyone. Er, no. Think about it. If EAPI is in file extension, the only concern for backwards compatibility is not reusing an existing valid extension. All we have to do is use a new EAPI value, and then we can change whatever we like because non-supporting package managers will ignore it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ryan Hill wrote: some other random ideas i've seen tossed around: - #!/bin/env eapi-parser - split EAPI into EAPI and some separate counter which would only be incremented on uncompatible changes to the ebuild format - change .ebuild to .eb - waffles (sorry, lunchtime) Yummy! -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
2009/2/24 Ferris McCormick fmc...@gentoo.org On Mon, 2009-02-23 at 22:19 +, Ciaran McCreesh wrote: On Mon, 23 Feb 2009 16:15:25 -0600 Ryan Hill dirtye...@gentoo.org wrote: Can we ban eclasses from setting EAPI? Is there any case where it would be sane? It's already banned from a QA perspective, but from a package manager perspective people have done it in the past and possibly still do do it, and the spec doesn't forbid it. For what it's worth, no eclass in the gentoo-x86/eclass tree sets EAPI. I don't know about anyplace else. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) lucene-contrib eclass in java-experimental [1] sets EAPI to 1 to use slot deps. And I think that's a valid usage. 1: http://overlays.gentoo.org/proj/java/browser/java-experimental/eclass/lucene-contrib.eclass
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 20:49:02 -0500 Richard Freeman ri...@gentoo.org wrote: and it doesn't let you change name or version rules. Neither does putting the EAPI in the filename as far as I can tell. Name or versioning rules are things like allowing new suffixes or altering the restrictions upon formatting. Currently, package managers assume that they can handle anything named pkg-$anything.ebuild, and $anything has to be a valid version spec by the current rules. Version rules have changed at least twice in the past, and it's been messy every time. 55 allows version changes to be done safely (although not carelessly...). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Richard Freeman wrote: I still don't see why we need to be encoding metadata in filenames. Correct. GLEP 55 tries to solve a technical implementation issue by exposing meta data in the filename. Extremely bad form/design, IMHO. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. All good points. I cannot believe there exists no other way to solve this technical issue other than resorting to such a non-Unix-like idea. Obviously all of the software packages cited above endeavor to avoid such nastiness. I do not understand why anyone is willing to accept putting version info in the filename/extension. It is inelegant and, frankly, very ugly. I have written more in the past on why I think it is a terrible idea, so I won't repeat it here. Suffice to say, if something like GLEP 55 is implemented, I will lose a lot of faith in Gentoo's design, so much so that I will likely join the ranks of those who abandon it, not only as a dev, but also as a user. This seems to me to be a solved problem. You put a header in a file that tells you how to read the file. Headers are split into fields and if a program doesn't know what to do with a field it ignores it (or if the header so instructs it doesn't even try to parse the file). This should be easy to do and keep the file bash-compatible. Just stick a comment line close to the top of the file and put whatever you want on it. You could also stick something in metadata.xml (although this makes working with ebuilds outside of a repository more difficult). You run the file through an algorithm to find out what the EAPI is, and then source it if appropriate. Sure, if you make some major change analogous to switching from the .rpm to the .deb package format then maybe an extension change would make sense. But, why expose the inner workings of the package file format to the filesystem? +100 -Joe
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Somewhat ironically, had everyone been less stubborn last year when discussing this topic we could have embedded the EAPI in line X of the ebuild in 2008 and be using it now; instead of still discussing it. I don't expect new novel ideas out of this thread. I expect the council to defer it again because the arguments are the same as last time and last time they were not convincing enough. I would prefer if the council went one way or the other so that when we are arguing about this in 2010 we can at least say hey we have support in $PACKAGE_MANAGERs for EAPI on line X since May 2009 so in 3 months we can just switch. We don't have to make the switch; I'm just saying we should add support to hedge our bets. Thoughts? -A
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 09:15:59 -0700 Joe Peterson lava...@gentoo.org wrote: Richard Freeman wrote: I still don't see why we need to be encoding metadata in filenames. Correct. GLEP 55 tries to solve a technical implementation issue by exposing meta data in the filename. Extremely bad form/design, IMHO. We already expose metadata in the filename. The version's there and the name's there. All good points. I cannot believe there exists no other way to solve this technical issue other than resorting to such a non-Unix-like idea. Obviously all of the software packages cited above endeavor to avoid such nastiness. Then why don't you come up with a viable solution? I do not understand why anyone is willing to accept putting version info in the filename/extension. It is inelegant and, frankly, very ugly. I have written more in the past on why I think it is a terrible idea, so I won't repeat it here. For the same reason they're willing to accept the package name and version in the filename. Suffice to say, if something like GLEP 55 is implemented, I will lose a lot of faith in Gentoo's design, so much so that I will likely join the ranks of those who abandon it, not only as a dev, but also as a user. If you paint the bikeshed, I shall throw my toys out of the pram and run off crying.. Why don't you propose a viable alternative instead of making threats? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 08:21:25 -0800 Alec Warner anta...@gentoo.org wrote: Somewhat ironically, had everyone been less stubborn last year when discussing this topic we could have embedded the EAPI in line X of the ebuild in 2008 and be using it now; instead of still discussing it. ...and we wouldn't be able to change the version rules, and we would be suffering a substantial performance hit. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Richard Freeman wrote: The dynamic linker doesn't need to consult the filename to figure out how to parse a shared object. It only consults the filename to figure out which shared object is needed. That is actually analogous to putting the package name/version in the ebuild filename. Right. Plus, if the linker *did* consult the filename, imagine what would happen if someone renamed the file (even by accident) and changed the version? The parser should not be able to be so easily fooled - could cause great confusion and or nasty and weird bugs - seems very fragile to me. Having the version *in* the file is much safer, since monkeying with that would require editing it the file, rather than renaming it. -Joe
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 09:24:48 -0700 Joe Peterson lava...@gentoo.org wrote: Right. Plus, if the linker *did* consult the filename, imagine what would happen if someone renamed the file (even by accident) and changed the version? The parser should not be able to be so easily fooled - could cause great confusion and or nasty and weird bugs - seems very fragile to me. Having the version *in* the file is much safer, since monkeying with that would require editing it the file, rather than renaming it. You could use the same absurd argument to say that PN and PV shouldn't be in the filename... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, Feb 24, 2009 at 8:23 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 08:21:25 -0800 Alec Warner anta...@gentoo.org wrote: Somewhat ironically, had everyone been less stubborn last year when discussing this topic we could have embedded the EAPI in line X of the ebuild in 2008 and be using it now; instead of still discussing it. ...and we wouldn't be able to change the version rules, and we would be suffering a substantial performance hit. Hey I never said its a perfect solution; but I'm a fan of the 'it covers 80%'. Sometimes you can't have your cake and eat it too; sometimes requirements get dropped. -A -- Ciaran McCreesh
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Tue, 24 Feb 2009 09:24:48 -0700 Joe Peterson lava...@gentoo.org wrote: Right. Plus, if the linker *did* consult the filename, imagine what would happen if someone renamed the file (even by accident) and changed the version? The parser should not be able to be so easily fooled - could cause great confusion and or nasty and weird bugs - seems very fragile to me. Having the version *in* the file is much safer, since monkeying with that would require editing it the file, rather than renaming it. You could use the same absurd argument to say that PN and PV shouldn't be in the filename... No...! They are needed because: 1) versions of the *content*, not the *format* are needed for uniqueness 2) it makes sense to have these in the filename, but not internal meta-data
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 08:33:19 -0800 Alec Warner anta...@gentoo.org wrote: Hey I never said its a perfect solution; but I'm a fan of the 'it covers 80%'. Sometimes you can't have your cake and eat it too; sometimes requirements get dropped. We can cover 100% with a solution with less of an impact. There's no need to compromise here. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 08:33:19 -0800 Alec Warner anta...@gentoo.org wrote: Hey I never said its a perfect solution; but I'm a fan of the 'it covers 80%'. Sometimes you can't have your cake and eat it too; sometimes requirements get dropped. We can cover 100% with a solution with less of an impact. There's no need to compromise here. Two years to argue and implement a solution certainly shouts compromise to me. -A -- Ciaran McCreesh
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 09:36:29 -0700 Joe Peterson lava...@gentoo.org wrote: You could use the same absurd argument to say that PN and PV shouldn't be in the filename... No...! They are needed because: 1) versions of the *content*, not the *format* are needed for uniqueness So why's PN in there then? 2) it makes sense to have these in the filename, but not internal meta-data For those of us who understand the process, it makes sense to have EAPI in the filename too. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 09:45:44 -0700 Joe Peterson lava...@gentoo.org wrote: Then why don't you come up with a viable solution? I already have - look back at my posts; very similar to Rich0's idea. No, I said viable. And I tire of the argument that if one doesn't have a perfect solution now, we should adopt a half-brained one. The point of this is to spur discussion to come up with a better solution. We have a perfect solution. For the same reason they're willing to accept the package name and version in the filename. The fact that you think this is the same thing as having the EAPI in the filename is odd. PN and PV are metadata, same as EAPI. If you paint the bikeshed, I shall throw my toys out of the pram and run off crying.. Why don't you propose a viable alternative instead of making threats? Not a threat. And this will be my last post on the topic. I will not take your bate and continue to argue, creating more noise on this list - I've expressed how I feel. This isn't about how you feel. It's about what you rationally think, based upon a full understanding of the issues at hand. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Tue, 24 Feb 2009 08:42:44 -0800 Alec Warner anta...@gentoo.org wrote: On Tue, Feb 24, 2009 at 8:37 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Tue, 24 Feb 2009 08:33:19 -0800 Alec Warner anta...@gentoo.org wrote: Hey I never said its a perfect solution; but I'm a fan of the 'it covers 80%'. Sometimes you can't have your cake and eat it too; sometimes requirements get dropped. We can cover 100% with a solution with less of an impact. There's no need to compromise here. Two years to argue and implement a solution certainly shouts compromise to me. Strange. To me it shouts leadership problem. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.)
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Complicates the implementation (annoying), but more importantly negates one of the features of g55- being able to tell via the extension if the manager supports that EAPI. Honestly, the issue isn't breaking sourcing (literally unable to source it) of the ebuild as much as sourcing it *wrong*- simplest example, new metadata key is added in eapi 1.3, compliant implementations have to pull that key out of the env and put it in the cache. Sourcing on the surface, would succeed- but the results would be worthless (it'd basically be similar to the situation now). ~brian pgpeX8pilTQ8r.pgp Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Personally I don't see what the problem is with simply implementing GLEP-55. It's the best solution. It should be pretty simple to implement too. Certainly it wouldn't be anymore difficult to implement than your solution. Maybe once zmedico finishes his latest development push I will attempt to implement it.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Yes, sure. I was just looking for a solution for the we have countless .eapi-X after 10 years problem. Personally I don't see what the problem is with simply implementing GLEP-55. It's the best solution. It should be pretty simple to implement too. Certainly it wouldn't be anymore difficult to implement than your solution. I fully agree. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote: Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Yes, sure. I was just looking for a solution for the we have countless .eapi-X after 10 years problem. No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. With a little common sense and planning, we could make this a non-issue and give ebuild authors and PM devs alike a little time to get used to each change.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote: On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote: Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Yes, sure. I was just looking for a solution for the we have countless .eapi-X after 10 years problem. No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. With a little common sense and planning, we could make this a non-issue and give ebuild authors and PM devs alike a little time to get used to each change. There also is the angle that deploying g55 requires waiting at least a full stage release (~year, at least by the old standards) to ensure people aren't screwed by the repository changing formats (unversioned!) under their feet. I'd point out that g55 isn't even accepted (search the archives for the debates), but folks seem to be ignoring that and the issues of just flipping the switch... ~harring, aka the version the farking repo format so stuff like this can be done cleanly guy pgpo6FSu5I42q.pgp Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Makes you getting to have to do the two stage source again AND you get another non obvious condition Should I bump the eapi internally or the filename? The main point again what is proposed in glep-55 is it that isn't invasive and non-transparent to users and developers. As stated in the analysis, the user side is already covered by the fact users use the cache, the developer side would require a two stage sourcing when committing to remain transparent. What we need to balance is if the invasive proposal is simpler than having a two stage sourcing done. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote: Tiziano M??ller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Makes you getting to have to do the two stage source again AND you get another non obvious condition Should I bump the eapi internally or the filename? The glep is quite clear on that point. The main point again what is proposed in glep-55 is it that isn't invasive and non-transparent to users and developers. It's not all that invasive. All that changes is that the EAPI goes at the end of the filename and you don't set it in the ebuild. Developers should be able to keep up with this, and if a user asks it's easy enough to say that it's a new version of ebuild, it has newer features see www.blah.org/blah for details. And really, users already ask what EAPI is so it's not that much headache. -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpb1wKek30va.pgp Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Brian Harring ferri...@gmail.com posted 20090223085232.ga6...@hrair, excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800: On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: [quoting...] What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people[...] Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Complicates the implementation (annoying), but more importantly negates one of the features of g55- being able to tell via the extension if the manager supports that EAPI. That makes sense, but from my observation, the biggest resistance is coming from potentially unlimited changes to the extension. That rubs some people strongly enough the wrong way to have folks threatening to leave over it, etc. If it must be, it must be, but obviously, if there's a /reasonable/ way to avoid it, we should. Way back when this first came up, I asked a simple question and IIRC wasn't satisfied with the answer. Since the elements of it have been proposed separately, perhaps it's time to ask about the combination once again, as it seems to me to solve both the technical and aesthetic issues, tho admittedly it does have a bit of the complicates the implementation problem. As I understand it, the nastiest technical problem is currently the chicken/egg issue of needing the EAPI to source the ebuild... to /get/ the EAPI. Above, we have what amounts to a major/minor EAPI proposal, stick the major in the extension (or as a variant, the pre-extension filename), with it bumped only when the format changes enough to require pre-source knowledge of the change. Elsewhere, someone proposed strenthening the format rules by hard- specifying a location and format for the EAPI line, say line two of the ebuild and in a format specific enough to be parsed /without/ sourcing the ebuild, thus providing a pre-source method for grabbing the EAPI. The shoot-down when originally suggested was that this isn't flexible enough. It's also arguably less efficient since one has to access the file twice, first to get the EAPI, then to actually source the file. Unfortunately the below suggestion doesn't avoid that. Combining the two ideas, we get: Why not put the EAPI-major aka pre-parse-EAPI in that hard-specified in-file location, thus giving the package manager a method to grab it pre- source, then allow more flexibility on the EAPI-minor aka post-parse-EAPI? FWIW, all EAPIs to date have been EAPI-minor/post-parse, precisely /because/ of the need-the-EAPI-to-source-to-get-the-EAPI issue. This would eliminate that issue, providing both the necessary pre-source (major) EAPI solution and flexibility on the post-source (minor) EAPI. It would also avoid the so controversial aesthetic issue, maintaining the traditional .ebuild extension. The negative, however, as mentioned, is that of efficiency. It'd be necessary to access the file twice, pre-source to get the EAPI-major, then the source to fill in all the details. Putting just the EAPI-major in the filename/extension would avoid the first access (a dir listing would suffice) and using the filename for the EAPI entirely would in some cases possibly avoid accessing the file itself entirely -- at the expense of EAPI flexibility and aesthetics. Meanwhile, a status/process observation, if I may. Given the efficiency negative of putting the EAPI anywhere /but/ the filename and the way the debate has gone, GLEP-55 or something close to it (using the filename for EAPI) would appear headed toward ultimate approval, however slow it seems to be getting there. The major blocker would appear to be that the GLEP as-is simply doesn't sufficiently address everything that has come up in the discussions. As such, it's not clearly and sufficiently enough worded for the council to feel comfortable approving it. Based on council logs and discussion, I get the STRONG impression that they are pretty much /begging/ the proponents to address this issue, updating the GLEP as appropriate, so they can /finally/ get out of the eternal debate stage and vote it up or down (presumably up as it doesn't appear they have a viable alternative either) on its merits, and the PMs can get it implemented and both the council and Gentoo can move on. Unfortunately, due to personnel issues, apparently there's currently nobody filling the triple qualifications of being (1) a strong enough proponent to bother, (2) a PM dev or other with sufficient grasp of the issues to actually /do/ the work, and (3) a Gentoo dev with the necessary
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 04:26:49 -0800 Brian Harring ferri...@gmail.com wrote: There also is the angle that deploying g55 requires waiting at least a full stage release (~year, at least by the old standards) to ensure people aren't screwed by the repository changing formats (unversioned!) under their feet. No it doesn't. It's transparent to users using an older package manager. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 03:15:03 +0100 Luca Barbato lu_z...@gentoo.org wrote: Let's try to start with a common workflow for the user: - an user with an ancient version of portage syncs - it requires a package - it looks at the cache ($portdir/metadata/cache/) - picks the best entry from the ones showing an eapi it understands - keeps going. Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. 2- The user will get unpredictable behavior, but portage tell you when upgrading is needed... Not if the version you'd need to do metadata generation is ~arch it doesn't. 3- you'd have to disable them Yes, tell everyone to disable all the overlays that make use of a few features only in ~arch package managers... That'll work... In this case we have a problem if the source step is a single one, portage won't know in advance how to behave. So the first step has to be split in two: - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. The problem is that right now sourcing is done by having an instructed bash. So the simplest way to get the first step done is parsing the ebuild file with something different like file(1) and then instruct bash and do the parsing. file(1) can't parse ebuilds. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. There's no surprise at all. It's extremely clear. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 01:50:10PM +, Ciaran McCreesh wrote: On Mon, 23 Feb 2009 04:26:49 -0800 Brian Harring ferri...@gmail.com wrote: There also is the angle that deploying g55 requires waiting at least a full stage release (~year, at least by the old standards) to ensure people aren't screwed by the repository changing formats (unversioned!) under their feet. No it doesn't. It's transparent to users using an older package manager. Would be useful if someone pulled older portage versions and checked exactly what they do in this case- explode, behave, etc (manifest behaviour included). It's been several years, but I recall portage having problems at the onset of EAPI w/ it. Beyond that, what I was stating was that the user doesn't get told sorry, your manager is too old, upgrade- kind of an unobvious failing. Frankly, in terms of g55 I don't particularly care if it were implemented- although I'd rather see it go in a seperate repo along w/ the dozen other fixups needed, preferably starting w/ overlays... ~harring pgplVR5glWTvH.pgp Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 06:15:25 -0800 Brian Harring ferri...@gmail.com wrote: No it doesn't. It's transparent to users using an older package manager. Would be useful if someone pulled older portage versions and checked exactly what they do in this case- explode, behave, etc (manifest behaviour included). It's been several years, but I recall portage having problems at the onset of EAPI w/ it. It was checked back when 55 was originally written. If it's broken now, it's a breakage since then... Frankly, in terms of g55 I don't particularly care if it were implemented- although I'd rather see it go in a seperate repo along w/ the dozen other fixups needed, preferably starting w/ overlays... Well yes, but that's never realistically going to happen. 55's one of the few repository format fixes that can happen in a reasonable timeframe. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Douglas Anderson wrote: No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. I got the impression that if anything there is a desire to allow EAPIs to change more offen, and not less. And these changes could become more dramatic. I'm not sure this is actually a bad thing (within reason - we do need to have clear specifications for anything that hits production so that we don't have a package manager mess). Also - keep in mind that EAPIs do not need to be numbers and are not ordered. You could have ebuild-i_am_a_furry_monkey or ebuild-bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays. Sure - hopefully the names will be more sensible and somewhat uniform, but we're not necessarily just talking about adding a number to the extension. I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. This seems to me to be a solved problem. You put a header in a file that tells you how to read the file. Headers are split into fields and if a program doesn't know what to do with a field it ignores it (or if the header so instructs it doesn't even try to parse the file). This should be easy to do and keep the file bash-compatible. Just stick a comment line close to the top of the file and put whatever you want on it. You could also stick something in metadata.xml (although this makes working with ebuilds outside of a repository more difficult). You run the file through an algorithm to find out what the EAPI is, and then source it if appropriate. Sure, if you make some major change analogous to switching from the .rpm to the .deb package format then maybe an extension change would make sense. But, why expose the inner workings of the package file format to the filesystem?
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 09:28:06 -0500 Richard Freeman ri...@gentoo.org wrote: I got the impression that if anything there is a desire to allow EAPIs to change more offen, and not less. And these changes could become more dramatic. But we're still only talking maybe three new EAPIs a year. Also - keep in mind that EAPIs do not need to be numbers and are not ordered. You could have ebuild-i_am_a_furry_monkey or ebuild-bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays. Sure - hopefully the names will be more sensible and somewhat uniform, but we're not necessarily just talking about adding a number to the extension. You're using developers might do something really stupid as an argument? By that logic, the current setup sucks since someone might make an EAPI called a'bc\d , so developers might have to put weird escaping in when specifying EAPI. Also note that kdebuild went with .kdebuild-1, not .ebuild-kdebuild-1. It's no leap to have slightly different extension rules for any project that creates its own non-numerical EAPIs. I still don't see why we need to be encoding metadata in filenames. Because the metadata has to be known before the file can be used. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. Back when Perl 5 and PHP 5 were new, people often used extensions like .php4 and .php5 to tell their webserver how to handle scripts... This seems to me to be a solved problem. You put a header in a file that tells you how to read the file. Headers are split into fields and if a program doesn't know what to do with a field it ignores it (or if the header so instructs it doesn't even try to parse the file). This should be easy to do and keep the file bash-compatible. Just stick a comment line close to the top of the file and put whatever you want on it. That doesn't work with existing packages or existing package managers. Sure, if you make some major change analogous to switching from the .rpm to the .deb package format then maybe an extension change would make sense. But, why expose the inner workings of the package file format to the filesystem? For the same reason versions and package names are already in the filename. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Mon, 23 Feb 2009 03:15:03 +0100 Luca Barbato lu_z...@gentoo.org wrote: Let's try to start with a common workflow for the user: - an user with an ancient version of portage syncs - it requires a package - it looks at the cache ($portdir/metadata/cache/) - picks the best entry from the ones showing an eapi it understands - keeps going. Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. When it isn't? 2- The user will get unpredictable behavior, but portage tell you when upgrading is needed... Not if the version you'd need to do metadata generation is ~arch it doesn't. ... 3- you'd have to disable them Yes, tell everyone to disable all the overlays that make use of a few features only in ~arch package managers... That'll work... disable overlays to UPGRADE to the new portage. Not rocket science... In this case we have a problem if the source step is a single one, portage won't know in advance how to behave. So the first step has to be split in two: - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. If you are generating the cache you must have a way to know it... The problem is that right now sourcing is done by having an instructed bash. So the simplest way to get the first step done is parsing the ebuild file with something different like file(1) and then instruct bash and do the parsing. file(1) can't parse ebuilds. file parses quite well avi and mov, ebuild will be anytime more complex than that right? Anyway it isn't a problem since the version of portage doing the work is supposed to be up to date, if isn't it will be updated first using the normal user workflow that has already been covered by the cache. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. That is always the case since you are adding an ebuild and you are supposed to have an up to date portage in order to do that. What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. There's no surprise at all. It's extremely clear. Not that much. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 15:46:24 +0100 Luca Barbato lu_z...@gentoo.org wrote: Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. When it isn't? Every now and again (probably after someone changes eutils...), rsync mirrors end up shipping a load of stale metadata for parts of the tree. Portage users probably don't notice, since it just causes a slowdown. disable overlays to UPGRADE to the new portage. Not rocket science... No no. You're forcing people to switch to ~arch to be able to use overlays. In this case we have a problem if the source step is a single one, portage won't know in advance how to behave. So the first step has to be split in two: - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. If you are generating the cache you must have a way to know it... No, we don't. That's the entire frickin' point of GLEP 55, and one that you would do well to understand fully before commenting further. The way we generate metadata now is massively horrible, and only works because there aren't any serious global scope differences between EAPIs. We can't make any global scope changes to future EAPIs because it breaks current metadata generation. Right now it's safe to pretend EAPI 0 until the real EAPI is worked out, but that won't hold in the future -- as soon as global scope changes come along, there's no safe EAPI that can be assumed, even if we didn't have to worry about breaking existing package managers. The problem is that right now sourcing is done by having an instructed bash. So the simplest way to get the first step done is parsing the ebuild file with something different like file(1) and then instruct bash and do the parsing. file(1) can't parse ebuilds. file parses quite well avi and mov, ebuild will be anytime more complex than that right? It's already *way* more complicated than that. Extracting metadata requires a full bash 3 implementation along with a considerable amount of supporting code. Anyway it isn't a problem since the version of portage doing the work is supposed to be up to date, if isn't it will be updated first using the normal user workflow that has already been covered by the cache. Most users don't run ~arch, and do use overlays. So no, this will affect normal user workflow. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. That is always the case since you are adding an ebuild and you are supposed to have an up to date portage in order to do that. Again, you're not getting it. Doesn't matter how up to date your package manager is. You can't find out the EAPI unless you already know the EAPI. What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. There's no surprise at all. It's extremely clear. Not that much. How is '.ebuild-3' being used to specify version 3 of the ebuild format in the least bit surprising? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Richard Freeman wrote: I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. I have to admit I'm in the same camp with Richard, and don't understand the necessity. I'm also opposed to creating arbitrary suffixes to the ebuild extension, for cosmetic and compatibility reasons. Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? Steve
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.ebuild:
EAPI=${PV}
printf -v EAPI '%s' 4
inherit foo
EAPI=2
In foo.eclass:
EAPI=3
And in this case, the package manager has to know that EAPI=2, and it
has to use EAPI 2's behaviour for performing the inherit.
In fact, it gets worse if you consider that future EAPIs will probably
allow per-package eclasses. So you could end up with this crazy
situation:
In pkg-1.ebuild:
require pkg
In cat/pkg/pkg.eclass:
EAPI=3
In global pkg.eclass:
EAPI=2
So here you can't even use a faked pre-source EAPI. If you assume EAPI
0 beforehand, the global pkg.eclass will be used, so EAPI will end up
as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be
used, so the EAPI will end up as 3.
It gets even crazier if you put EAPI=2 in the per-pkg eclass and
EAPI=3 in the global one instead...
And whilst this is clearly a deliberate example of how to create
craziness, the only difference between this and the real world is that
the craziness is obvious here. The current rules really are this
complicated, and we can't retroactively fix them.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb bean...@gentoo.org wrote: Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? The problem is that its technically allowed for the value of $EAPI to be dependent on other bits and pieces. For instance: if [[ $PV = 2.6 ]] then EAPI=2 else EAPI=1 fi The quick-n-dirty solution to that is to just say that EAPI is not just a bash variable, it's also a magic string, so manipulating it in bash is forbidden. And please place it in line 5 of your ebuild, kthxbye. To be honest I see no good reason for allowing manipulation of it, but I'm sure other people will tell me why adding this requirement at this point is wrong even though no ebuilds in the tree to the best of my knowledge use EAPI as anything more than a declaration that's placed Just before inherit, right after the header. /loki_val
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 17:06:17 +0100 Peter Alfredsen loki_...@gentoo.org wrote: To be honest I see no good reason for allowing manipulation of it, but I'm sure other people will tell me why adding this requirement at this point is wrong There's not really a good reason to allow manipulating it (and, obviously, with GLEP 55 manipulating it becomes impossible), but since for all current EAPIs it's just defined as a metadata variable that's generated in the same way as things like SLOT, manipulating it is unfortunately legal. even though no ebuilds in the tree to the best of my knowledge use EAPI as anything more than a declaration that's placed Just before inherit, right after the header. People have, in the past, set EAPI inside eclasses. It's stupid and horrible, but they've done it. But here's the thing -- even if we retroactively enforce a new rule requiring it to be specified in a particular way right after the header (which is bad, since it breaks things people have already done), it *still* doesn't let us change global scope behaviour since current package managers don't extract EAPI the horrid way. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in
one line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.ebuild:
EAPI=${PV}
printf -v EAPI '%s' 4
inherit foo
EAPI=2
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit restriction
in the file extension version) then this can be parsed easily with
grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree
has to be checked before implementing this and we'll have to wait a
good amount of time before breaking the current eapi bash-parsing but
I'm not aware of any eapi proposal that would break the current behavior
and would be usable in the main tree within a reasonable amount of
time such that we can't ignore backward compatibility.
In foo.eclass:
EAPI=3
I thought this was prohibited.
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 17:13:16 +0100 Alexis Ballier aball...@gentoo.org wrote: Which begs the question: is it really worth allowing it? If we only allow constant assignments (which is an implicit restriction in the file extension version) then this can be parsed easily with grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree has to be checked before implementing this and we'll have to wait a good amount of time before breaking the current eapi bash-parsing but I'm not aware of any eapi proposal that would break the current behavior and would be usable in the main tree within a reasonable amount of time such that we can't ignore backward compatibility. ...and then we have to do the whole thing again every time something new crops up. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. In foo.eclass: EAPI=3 I thought this was prohibited. It's legal, and people have done it, but it's considered by most people to be a horrible QA violation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:19:56 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 23 Feb 2009 17:13:16 +0100 Alexis Ballier aball...@gentoo.org wrote: Which begs the question: is it really worth allowing it? If we only allow constant assignments (which is an implicit restriction in the file extension version) then this can be parsed easily with grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree has to be checked before implementing this and we'll have to wait a good amount of time before breaking the current eapi bash-parsing but I'm not aware of any eapi proposal that would break the current behavior and would be usable in the main tree within a reasonable amount of time such that we can't ignore backward compatibility. ...and then we have to do the whole thing again every time something new crops up. Please give an example because I fail to see how. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 17:48:27 +0100 Alexis Ballier aball...@gentoo.org wrote: ...and then we have to do the whole thing again every time something new crops up. Please give an example because I fail to see how. New version suffix rules. New bash versions. New package naming rules. Partially composable EAPIs. Tree-provided internals. Consistent variable namespacing. Metadata via function calls. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... And we'd be starting on the next batch of oh, we need to wait another year. Had GLEP 55's necessity been accepted a year ago, we'd have a whole bunch of requested features implemented by now. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.ebuild:
EAPI=${PV}
printf -v EAPI '%s' 4
inherit foo
EAPI=2
In foo.eclass:
EAPI=3
This is not legal, the devmanual[1] explicitly states that it is not
legal to set EAPI in an eclass. If it was you would have an open and
shut case for g55 (since you could set EAPI based on PV in an eclass
and then inherit the eapi; requiring a bash parser). But its illegal,
which makes your argument harder.
A bad argument is EAPI based on some PV logic that you can copy across
ebuilds that differ by version; which would fall into 'stupid' in my
book.
[1] http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
And in this case, the package manager has to know that EAPI=2, and it
has to use EAPI 2's behaviour for performing the inherit.
In fact, it gets worse if you consider that future EAPIs will probably
allow per-package eclasses. So you could end up with this crazy
situation:
In pkg-1.ebuild:
require pkg
In cat/pkg/pkg.eclass:
EAPI=3
In global pkg.eclass:
EAPI=2
Also illegal, but I assume here you intend to change the legality of
things in your weird future example.
So here you can't even use a faked pre-source EAPI. If you assume EAPI
0 beforehand, the global pkg.eclass will be used, so EAPI will end up
as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be
used, so the EAPI will end up as 3.
It gets even crazier if you put EAPI=2 in the per-pkg eclass and
EAPI=3 in the global one instead...
And whilst this is clearly a deliberate example of how to create
craziness, the only difference between this and the real world is that
the craziness is obvious here. The current rules really are this
complicated, and we can't retroactively fix them.
--
Ciaran McCreesh
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 11:02:17 -0800 Alec Warner anta...@gentoo.org wrote: In foo.eclass: EAPI=3 This is not legal, the devmanual[1] explicitly states that it is not legal to set EAPI in an eclass. That's purely a QA thing, and it only applies to repositories that follow Gentoo's QA rules. It's in the same category as rules about what indenting style to use, not rules about how variables are formatted. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even
ld-linux.so doesn't care. I'm sure that in at least some of these
cases they end up parsing parts of the file twice - once to figure
out what it is, and the second time to actually handle it. I'm
actually hard pressed to think of any unix-based software that uses
the filename to store a mandatory file format versioning specifier
of some kind.
$ ls /usr/lib
I have to admit I'm in the same camp with Richard, and don't
understand the necessity. I'm also opposed to creating arbitrary
suffixes to the ebuild extension, for cosmetic and compatibility
reasons.
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not really. Let's play Guess the EAPI. :o
1.
-
EAPI=1
2. (with myeclass.eclass containing EAPI=2)
-
EAPI=1
inherit myeclass
-
3. (with myeclass.eclass containing EAPI=2)
-
EAPI=5
inherit myeclass
-
1. 1 (simple enough)
2. 2 (because myeclass.eclass sets EAPI=2)
3. 5 (inherit was changed in EAPI 5 to not overwrite ${EAPI} if
already set in an ebuild)
So you see, it's not as easy as a grep command. You need to source the
ebuild to know how things like inherit will affect the environment.
And without knowing the EAPI, you don't know which version of inherit to
call.
(i hope i have this right. feel free to call me names if i don't)
--
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
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Mon, 23 Feb 2009 17:48:27 +0100 Alexis Ballier aball...@gentoo.org wrote: ...and then we have to do the whole thing again every time something new crops up. Please give an example because I fail to see how. New version suffix rules. New bash versions. New package naming rules. Partially composable EAPIs. Tree-provided internals. Consistent variable namespacing. Metadata via function calls. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... And we'd be starting on the next batch of oh, we need to wait another year. Had GLEP 55's necessity been accepted a year ago, we'd have a whole bunch of requested features implemented by now. I doubt Portage would have gained new features any faster. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 21:30:04 +0200 Petteri Räty betelge...@gentoo.org wrote: And we'd be starting on the next batch of oh, we need to wait another year. Had GLEP 55's necessity been accepted a year ago, we'd have a whole bunch of requested features implemented by now. I doubt Portage would have gained new features any faster. Some useful things that are currently difficult become a lot easier to implement with GLEP 55. Per-package eclasses, for example, are easy if you don't have to care about the upgrade path, as is replacing versionator with a package manager internal. The complexity for both of those is in the upgrade path, not the implementation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ryan Hill wrote: On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb bean...@gentoo.org wrote: Richard Freeman wrote: I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. $ ls /usr/lib ldconfig ? I have to admit I'm in the same camp with Richard, and don't understand the necessity. I'm also opposed to creating arbitrary suffixes to the ebuild extension, for cosmetic and compatibility reasons. Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? Not really. Let's play Guess the EAPI. :o 1. - EAPI=1 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid - 3. (with myeclass.eclass containing EAPI=2) - EAPI=5 inherit myeclass Invalid So you see, it's not as easy as a grep command. You need to source the ebuild to know how things like inherit will affect the environment. And without knowing the EAPI, you don't know which version of inherit to call. It it isn't invalid already... (i hope i have this right. feel free to call me names if i don't) Names! lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 21:51:11 +0100 Luca Barbato lu_z...@gentoo.org wrote: 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid QA violation, but legal and a pain in the ass. 3. (with myeclass.eclass containing EAPI=2) - EAPI=5 inherit myeclass Invalid QA violation, but legal and a pain in the ass. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 20:54:38 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 23 Feb 2009 21:51:11 +0100 Luca Barbato lu_z...@gentoo.org wrote: 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid QA violation, but legal and a pain in the ass. I didn't think it was a brainy thing to do, but I can't find anything saying it isn't allowed. It probably shouldn't be. 3. (with myeclass.eclass containing EAPI=2) - EAPI=5 inherit myeclass Invalid QA violation, but legal and a pain in the ass. Can we ban eclasses from setting EAPI? Is there any case where it would be sane? -- 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:15:25 -0600 Ryan Hill dirtye...@gentoo.org wrote: Can we ban eclasses from setting EAPI? Is there any case where it would be sane? It's already banned from a QA perspective, but from a package manager perspective people have done it in the past and possibly still do do it, and the spec doesn't forbid it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:15:25 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Mon, 23 Feb 2009 20:54:38 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 23 Feb 2009 21:51:11 +0100 Luca Barbato lu_z...@gentoo.org wrote: 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid QA violation, but legal and a pain in the ass. I didn't think it was a brainy thing to do, but I can't find anything saying it isn't allowed. It probably shouldn't be. Ah now i did. -- 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 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ryan Hill wrote: Richard Freeman wrote: I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. $ ls /usr/lib I was referring to a file FORMAT versioning scheme - not a file CONTENT versioning scheme. The formats of all the files in /usr/lib are generally identical. Where they vary it has nothing to do with their filenames. The reason for the version in the filenames is that the content is versioned. The dynamic linker doesn't need to consult the filename to figure out how to parse a shared object. It only consults the filename to figure out which shared object is needed. That is actually analogous to putting the package name/version in the ebuild filename. In any case, I'm not trying to say that these issues absolutely prevent the adoption of GLEP 55. It just leaves a sour taste in my mouth, and keeps nagging at me that there must be a better way. I'd rather see the number of filename variations be kept to a minimum. Sure, if we were talking about a one-time change from ebuild to ebuild2 and in five years a change to ebuild3 then that would be one thing. It seems like we could be up to ebuild-kde4-3.2 in six months. And I don't mean to suggest that I don't think that efforts would be made to keep things sensible. It just seems like once we start down that road it will be hard to turn around if we don't like where we end up.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 18:47:07 -0500 Richard Freeman ri...@gentoo.org wrote: It seems like we could be up to ebuild-kde4-3.2 in six months. Why on earth do people think that? Of all the crazy being thrown around, this is the only one wearing a tutu. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Mon, 23 Feb 2009 18:47:07 -0500 Richard Freeman ri...@gentoo.org wrote: It seems like we could be up to ebuild-kde4-3.2 in six months. Why on earth do people think that? Of all the crazy being thrown around, this is the only one wearing a tutu. I suppose I'm exaggerating a little deliberately to make a point. It isn't so much that I don't think that people designing the extensions won't use sense, but that we're still potentially facing multiple new file extensions per year. Maybe not 15, but certainly 1-3. That can add up fast. If we had been doing this all along then we'd probably expect there to be upwards of 10-20 file extensions in portage today. It just seems like it isn't the best solution. You can get the same effect by just sticking something in a comment line a few lines into the ebuild in a fixed position. Sure, the file might need to be read twice, but unless the reading takes place widely separated in time the file is going to be in the cache the second time around. With proper caching you only need to scan files that have changed - we can't have that many daily commits, can we? I'll probably refrain from commenting further - I trust the council to weigh all the options and go with whatever makes the most sense. However, I did want to make it clear that I don't think that the folks advocating this approach are out to release 47 EAPI releases per year or anything...
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 19:17:19 -0500 Richard Freeman ri...@gentoo.org wrote: It just seems like it isn't the best solution. You can get the same effect by just sticking something in a comment line a few lines into the ebuild in a fixed position. No you can't. It doesn't work with existing package managers, and it doesn't let you change name or version rules. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Alistair Bush ali_b...@gentoo.org wrote: Tiziano Müller wrote: Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Actually, I think there would be a huge gain. The gain would be that suddenly all those who oppose glep-55 because they're afraid the filename suffix will change too often will suddenly have nothing to worry about. For those who think glep-55 is the right thing to do, it really *is* glep-55, but with a small caveat that we shouldn't just change the filename extension for every single little feature enhancement. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm,fluxbox,vim)
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman ri...@gentoo.org wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't work with existing package managers,
Agreed. This would require some delay in implementation and would
require users to have some minimal package manager version to handle
major changes in a repository.
and it
doesn't let you change name or version rules.
Neither does putting the EAPI in the filename as far as I can tell. It
isn't like you want to have ebuild filenames like:
foo-1.1.ebuild-\{EAPI\=1\ \;\ if\ \[\[\ \$PV\ =\ 2.6\ \]\]\ \;\ then\
EAPI\=2\ \;\ fi\}
Putting the EAPI in the filename forces it to be a rigid constant for
the purposes of determining how to parse the file. Putting the EAPI in
a comment line does the same. Both allow for dynamic manipulation of
the variable at a later stage of parsing, but this is after the package
manager has committed to sourcing the file in some particular manner.
If anything you get more flexibility putting it inside the file since at
least you can make it very long without clogging up command lines.
