Re: [gentoo-dev] GLEP 55 Version 2
On Sat, 2009-06-06 at 23:31 +0100, Roy Bamford wrote: I've spent some time reading all of this years emails on GLEP55 and added a few lines to version 1.5 which is the last offical version. Is there a specific reason not to include the inherit eapi[1][2] thing? IMHO this would fit best in Abstract Solution (Part 1) somehow like: -There are two potential solutions to this part of the problem, +There are three potential solutions to this part of the problem, * wait for old package managers to fall into disuse * 'blind' old package managers to ebuilds using later constructs + * use inherit to have old package managers almost silently + ignore unsupported ebuilds [1] http://archives.gentoo.org/gentoo-dev/msg_b2656aca1d124658b3df73d3d6804b7e.xml [2] http://archives.gentoo.org/gentoo-dev/msg_348f84690f03e597fb14d6602337c45f.xml Thanks! /haubi/ -- Michael Haubenwallner Gentoo on a different level
Re:[gentoo-dev] GLEP 55 Version 2
O Date: Sat, 06 Jun 2009 23:31:47 +0100 From: Roy Bamford neddyseag...@gentoo.org To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] GLEP 55 Version 2 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ladies and Gentlemen, I've spent some time reading all of this years emails on GLEP55 and added a few lines to version 1.5 which is the last offical version. The HTML version (not with the GLEP style sheet) is at http://xrl.us/bevrnb (my devspace) Its not ready to go to council as it still needs additional content which I don't have the background to contribuite. My role in this version of GLEP 55 has been interpretation and editorial. Very small point. There is a difference between EAPI in the file name extension and just EAPI in the file name. I think the intent here is the latter, but it speaks of them interchangeably it seems. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP 55 Version 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.06.08 16:48, Ferris McCormick wrote: [snip] Very small point. There is a difference between EAPI in the file name extension and just EAPI in the file name. I think the intent here is the latter, but it speaks of them interchangeably it seems. Regards, Ferris -- Ferris McCormick (P44646, MI) fmc...@gentoo.org Developer, Gentoo Linux (Sparc, Userrel, Trustees) Ferris, Its not a small point, it makes quite a difference. In most places the glep should talk about EAPI in the file name, not EAPI in the file name extension. dev-zero got to me first on that and I need to update the glep. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkotc4EACgkQTE4/y7nJvatWFwCeIyq5Ks/WzTUImTJXaoRQG5Pc x5QAnjOm+jfgQ5/3vBqJyPsRDOtc6YCF =yoel -END PGP SIGNATURE-
[gentoo-dev] GLEP 55 Version 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ladies and Gentlemen, I've spent some time reading all of this years emails on GLEP55 and added a few lines to version 1.5 which is the last offical version. The HTML version (not with the GLEP style sheet) is at http://xrl.us/bevrnb (my devspace) Its not ready to go to council as it still needs additional content which I don't have the background to contribuite. My role in this version of GLEP 55 has been interpretation and editorial. I'm looking for three elements to add. 1. A description of the steps the PM needs to extract the EAPI in ebuilds today, if its any more than sourcing the ebuild. 2. Benchmarks and supporting code for EAPI extraction for EAPI in the filename. 3. Benchmarks and supporting code for EAPI extraction for EAPI in the ebuild. Benchmarks for valid and invalid cache need to be supplied so we have both the user and developer views of performace. I expect items 2 and 3 to be provided by the proponents of these two competing options and critically examined for validity by the competitors. When the above data is available, I'll update the document as it needs to contain all of the evidence to allow council to reach a decision without reading the ml. Reply with corrections and factual additions with supporting evidence only please. The role of the GLEP is to present the evidence and make a reccomendation. Its councils job to make any subjective assessments having read the GLEP. - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoq7l8ACgkQTE4/y7nJvatqjQCeNe/mqS8goPZ5+H4yftn19mYJ 5i0AoLwsAmKcc6Ux4zjG3dExgRbcltwl =edR+ -END PGP SIGNATURE-
[gentoo-dev] GLEP 55: another approach: display pretty messages with old PMs
Hi,
As far as I can see, the basic problem with EAPI is that in EAPI 0 it
isn't specified how to specify the EAPI for an ebuild to be known at
pre-filename-parse-, pre-source- and post-source-time.
Ancient PM do not assume that there might be ebuilds they do not
understand. They only know how to deal with ebuilds that bash cannot
parse: mask by corruption.
To me, it looks like the most important point GLEP 55 tries to address
is how to have old PMs ignore an ebuild with unsupported EAPI without
making too much noise about it. Ok, one variant is to change the
extension to get it not being seen as ebuild at all.
IMHO, it is neither the masked by: corruption nor the Invalid ebuild
name message being the too-ugly-blocker, but the many red * error
lines before.
So why not look for a way to have old PMs mask such ebuilds by
corruption or Invalid ebuild name, but with an additional message as
short but explanatory as possible instead of the many ugly error-lines.
Looking a bit closer, it isn't portage's python code doing the ugly
error printing, but portage's bash-function 'die'.
Trying with portage-2.1.6.11 and bash-3.2_p39:
Portage does not display any ugly error message for an unsupported
ebuild, when this ebuild does 'exit' (either 'exit 0' or 'exit 1') in
global scope, so the '|| die' after the 'source $EBUILD' does not get
called.
And if there is another supported ebuild available for a given package
atom, even the 'masked by corruption' message is not shown.
So for how to 'exit' in global scope when the PM does not have
pre-source EAPI detection. Fortunately, we do have one global function
available in each EAPI: 'inherit'.
And here does my approach start:
I've tried some eapi.eclass doing the 'exit' in global scope,
eventually displaying a pretty message to inform the user to consider
upgrading the PM. This eclass has to be the first eclass inherited in
the ebuild, even before setting the actual EAPI.
To fulfill this requirement, and to make it easy for the PM to query the
EAPI without sourcing, we could specify to have the EAPI definition be
the first non-comment line, and to look like:
inherit eapi 4
Now when the PM is capable of pre-source EAPI detection, it will set
EAPI before sourcing, eapi.eclass can see EAPI already being set and not
do the 'exit' in global scope. Or even the PM's inherit-implementation
expects to be first called with arguments eapi 4, and not reading the
eapi.eclass at all, so the 'eapi.eclass' does not need to check for
anything, just needs to 'exit' when inherited.
After that 'inherit eapi X' line, we can specify EAPI X to do *whatever*
we want. It even does not need to be bash-sourceable.
Yes, it is a compromise, but it looks acceptable to me.
Attached is the eapi.eclass used for the following test (the 'ewarn'
inside can be replaced by something else if necessary):
Based on mico-2.3.13.ebuild (EAPI=0), I've added four ebuilds,
mico-2.3.13{-r1,-r2,-r3,_live}.ebuild, having these diffs based on the
extensions listed in GLEP 55:
Incompatible change of inherit:
$ diff mico-2.3.13{,-r1}.ebuild
3a4,5
inherit eapi 4
inherit some-local-eclass
New global scope function:
$ diff mico-2.3.13{,-r2}.ebuild
3a4,5
inherit eapi 4
some-new-global-scope-function
Use newer bash features:
$ diff mico-2.3.13{,-r3}.ebuild
3a4,8
inherit eapi 4
somelocalfunc() {
echo new bash features in local scope | cat
}
echo new bash features even in global scope | cat
New version format:
$ diff mico-2.3.13{,_live}.ebuild
3a4
inherit eapi 4
When there is an ebuild available that works with the current PM, the
emerge output would look like:
$ ACCEPT_KEYWORDS='~x86' emerge -1pv net-misc/mico
These are the packages that would be merged, in order:
Calculating dependencies |
Invalid ebuild name: /usr/portage/net-misc/mico/mico-2.3.13_live.ebuild
* Need =sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r3.
* Need =sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r2.
* Need =sys-apps/portage-2.3 to support net-misc/mico-2.3.13-r1.
...
done!
[ebuild N] net-misc/mico-2.3.13 USE=X gtk ssl threads -postgres
-qt3 -tcl 0 kB
Total: 1 package (1 new), Size of downloads: 0 kB
This is: one additional nice line for each unsupported ebuild, except
for the version format change, which shows 'Invalid ebuild name'.
But how many such new version formats will exist while there are no
other ebuilds with unsupported eapi but compatible version format, and
how long do we really plan to support PMs not pre-source reading the
eapi?
When there is no supported ebuild
[gentoo-dev] GLEP 55 updated
Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. Imho, council should first vote on whether they see the problem described in the GLEP as real (do we all agree on that at least?) and then pick one of these solutions. P.S. I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. [1] - http://dev.gentoo.org/~peper/glep-0055.html (http://www.gentoo.org/proj/en/glep/glep-0055.html once it synces) -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! /loki_val
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Piotr Jaroszyński pe...@gentoo.org: I have just updated GLEP 55 [1], hopefully making it a bit clearer. Thanks a lot Piotr. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change My preference goes to 3 with a .eb extension and EAPI on the first line. P.S. I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. We need all the problem solving people we can get. And since we're all volunteers there's no way we can force anybody to do anything. So, sure, there may be a need for prioritizing problems, but one problem solved is one less on the pile whatever it was. Denis.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. Ulrich [1] http://filext.com/file-extension/EB
Re: [gentoo-dev] GLEP 55 updated
On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen loki_...@gentoo.org wrote: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! I sincerely hope that was sarcasm. -- ~Nirbheek Chauhan
Re: [gentoo-dev] GLEP 55 updated
Denis Dupeyron wrote: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change My preference goes to 3 with a .eb extension and EAPI on the first line. I second this. :) Although I do not have a strong preference of in-file position, first line makes it like a she-bang, and that sounds good all around. -Joe
Re: [gentoo-dev] GLEP 55 updated
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. I also prefer 3. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. I like .eb but could also live with .gebuild as was suggested before. Ulrich [1] http://filext.com/file-extension/EB - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoQS84ACgkQcAWygvVEyAJ2gwCfUXuvc1f995QTxkElrPlY9I1H R6oAn0CMpXBe4Y8qnbkCleS3CgNbHJcK =kwqB -END PGP SIGNATURE-
Re: [gentoo-dev] GLEP 55 updated
On Sunday 17 May 2009 20:39:26 Jorge Manuel B. S. Vicetto wrote: Ulrich Mueller wrote: On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. I also prefer 3. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? Yeah, this sounds pretty reasonable to me :) -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
Jorge Manuel B. S. Vicetto wrote: As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? Well, if a she-bang, should be the first line. That also makes parsing a lot more straightforward and easily defined. Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. I like .eb but could also live with .gebuild as was suggested before. I'd hate to see the length grow - shrinking is better and cleaner. :) .gebuild is a little unwieldy IMHO. Also, since ebuilds can be used with distros other than gentoo itself, having the g there may not be a good idea. -Joe
Re: [gentoo-dev] GLEP 55 updated
Hi, On 2009/05/17, Piotr Jaroszyński pe...@gentoo.org wrote: I have just updated GLEP 55 [1], hopefully making it a bit clearer. In the GLEP, you raises the following argument against the Easily fetchable EAPI inside the ebuild class of solutions: Performance decrease comes from the fact that with version format changes in the picture package managers need EAPI to parse the ebuild's version. That means that merely picking the best version of a package requires loading EAPI (from cache or the ebuild) for each available ebuild. This argument is wrong imho. Future EAPIs can't be allowed to introduce backward-incompatible changes to the versions ordering rules, or they would make the PM behavior ill defined. Or, more precisely, if a PM adopts an EAPI with such a change, it has to drop support for the older incompatible ones. Let's take a very simple example: - eapi X says _p is equal to _p0 - eapi Y says _p is greater than any _pN -- of foo-1_p1 with EAPI=X and foo-1_p with EAPI=Y, what is the best version? So, basically, we are, and will stay, in a situation such that there is a complete order relation beetween all the version strings supported by at least one of the EAPIs implemented by the PM, and all the versionning rules of this EAPIs match this order relation. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string 2- among the remaining ones, parse and sort versions (sure, would actually be done together with step 1, for performances reasons) 3- get metadatas for the best one (generate or pick in cache), and check its EAPI that it is a supported one, and also that the version string is allowed in this EAPI 4- loop on step 3 if EAPI check failed It is as fast as the algorithm GLEP55 promotes, but in the case you're using an old package manager and there is really a lot of ebuild updates you skip because of unsupported EAPI (here you still fetch their metadata, but not with GLEP55). But i don't see it as a nominal case. Thanks, -- TGL.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 20:40:37 +0200 Thomas de Grenier de Latour tom...@free.fr wrote: This argument is wrong imho. Future EAPIs can't be allowed to introduce backward-incompatible changes to the versions ordering rules, or they would make the PM behavior ill defined. Or, more precisely, if a PM adopts an EAPI with such a change, it has to drop support for the older incompatible ones. Not exactly true. It means that EAPI version rules have to be mappable onto a single larger superversion format in such a way that they have a total order. Let's take a very simple example: - eapi X says _p is equal to _p0 - eapi Y says _p is greater than any _pN -- of foo-1_p1 with EAPI=X and foo-1_p with EAPI=Y, what is the best version? You don't define it quite like that. You define it by mapping EAPI X _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way the ordering's well defined. Although that's a fairly convoluted example, and not in line with what's being proposed for future EAPIs. What we're after is the ability to allow versions like 1.2.3-rc1. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string You don't know whether you recognise the version string until you know the EAPI, though. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 22:54:38 +0530 Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sun, May 17, 2009 at 9:36 PM, Peter Alfredsen loki_...@gentoo.org wrote: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. YES ! I sincerely hope that was sarcasm. I don't want us to get to a place where every single new feature has to be delayed by the objection We've got basic bugs we need to fix first. That's just unreasonable and a straw man. I get my kicks from improving things, not from fixing broken things. You may object and say they're one and the same, and you would not be wrong, but the emphasis *is* different. People seem to not see that in the case of GLEP 55 and some call for a moratorium on new features till we've fixed the bugs that already exist. Not gonna happen. The human spirit is what's driving Gentoo, giving it life. Our aspirations to improve the world around us lives and breathes with every ebuild we churn out. World domination is our goal and we won't get there by letting the maintainer-needed queue bog us down. I think that it's obvious to everybody that the problem GLEP 55 is solving is real. To me, .ebuild-$eapi/.eapi-$eapi.eb looks like the best solution, all things considered. From a purely unixy point-of-view, I see the cleanliness of a shebang EAPI definition, and that would be my second choice, but we need a solution we can use now. Not a year from now. Time really does matter. My dislike for the GLEP 55 process is my main reason for supporting GLEP 55 as-is. If we can skip just one more 50-mail thread because of GLEP55, it will be worth the extra work of typing -$eapi every now and then. Because seriously, if ever there was a mailing list topic whose only effect has been to act like a succubus, GLEP 55 is it. ( In other words: No sarcasm intended ) /loki_val
Re: [gentoo-dev] GLEP 55 updated
On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild From what I understand, the difference between 3 and 4 is that (4) would break pre-glep55 Portage versions that see an ebuild with no metadata cache present if the ebuild uses a future EAPI that introduces changes as described in the Current behaviour section. (4) would otherwise keep the current workflow the same except restricting the way the EAPI variable is defined in the ebuild. I would argue that most people who are be exposed to repositories that do not carry a metadata cache (overlays) which use new EAPIs also keep their portage version current. I'd say go with option (4) now and by the time EAPI 4 is collected, written up, agreed upon and implemented, enough time went by so we would not have to introduce an artificial delay. And after that, there won't be any delay to avoid breakage anymore. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
2009-05-17 20:57:25 Robert Buchholz napisał(a): On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild +1 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Robert Buchholz r...@gentoo.org: On Sunday 17 May 2009, Piotr Jaroszyński wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change Judging from this list, fourth option present in the GLEP is unacceptable for you? I would like to avoid user-visible breakage as much as possible. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] GLEP 55 updated
On 2009/05/17, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Let's take a very simple example: - eapi X says _p is equal to _p0 - eapi Y says _p is greater than any _pN -- of foo-1_p1 with EAPI=X and foo-1_p with EAPI=Y, what is the best version? You don't define it quite like that. You define it by mapping EAPI X _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way the ordering's well defined. I understand the idea, but I still don't think it's viable to allow such definitions, because there are too many contexts in which we manipulate pure version strings, without decorating them with an EAPI, and without reference to a concrete package from which we could get it. Take =bar/foo-1_p as an emerge command line argument for instance, is my foo-1_p1.ebuild a candidate? Although that's a fairly convoluted example, and not in line with what's being proposed for future EAPIs. What we're after is the ability to allow versions like 1.2.3-rc1. Right, and for this kind of reasonable future needs, it's easy enough to ensure enough backward compatibility so that we don't need to add the EAPI each time we talk about a version. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string You don't know whether you recognise the version string until you know the EAPI, though. Under my previously stated restrictions, you know: - which one can be rejected for sure (the ones not recognized by any of your implemented EAPI). - how to correctly order the remaining ones (even the incorrect ones which may remain and would be rejected only at step 4), and thus where to start to find the best correct one. Which is well enough. -- TGL.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 21:57:40 +0200 Thomas de Grenier de Latour tom...@free.fr wrote: On 2009/05/17, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: You don't define it quite like that. You define it by mapping EAPI X _p onto super-EAPI _p0, and EAPI Y _p onto super_EAPI _pINFINITY. That way the ordering's well defined. I understand the idea, but I still don't think it's viable to allow such definitions, because there are too many contexts in which we manipulate pure version strings, without decorating them with an EAPI, and without reference to a concrete package from which we could get it. Take =bar/foo-1_p as an emerge command line argument for instance, is my foo-1_p1.ebuild a candidate? Conceptually, you'd define a 'user' EAPI for those things, so you can define it any way you want (including in such a way that the _p thing works both ways depending upon the EAPI used for creating the thing you're comparing it to -- for the user EAPI, you'd define it as being _pUNSPECIFIED rather than _p0 or _pINFINITY and use the other side of the comparison to decide the result). But yes, if you do something silly like your example, things get very complicated. As a consequence, the algorithm for picking best version of a package can be as simple as the following: 1- among all ebuilds filenames, filter out the ones with unrecognized version string You don't know whether you recognise the version string until you know the EAPI, though. Under my previously stated restrictions, you know: - which one can be rejected for sure (the ones not recognized by any of your implemented EAPI). - how to correctly order the remaining ones (even the incorrect ones which may remain and would be rejected only at step 4), and thus where to start to find the best correct one. Your previously stated restrictions are too strong, though. And when it turns out a future change breaks those restrictions, we'd be back to yet another extension change. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
Let me first say that I think this revision is much improved, and makes it clearer what we are talking about. As to the stated problem(s): 1. Incompatible change of inherit (e.g. make it look in the package dir too) A case would need to be made, in my opinion, as to why we would wish to allow this in the first place. The current inherit behavior with eclasses in a central place works well enough. So I think we can disregard this. 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. GLEP54 is a valid use case, and I can see the value in that. Even so, using - and variations has worked for us so far, so I'm not convinced GLEP5455 as a package is a must have. 4. Use newer bash features This, in my opinion, would potentially be very useful to have. Altho it is certainly possible to continue with bash 3.0 as we have done so far, certain newer features are nice to be able to use. All in all I am still not sold on the perceived problems, and therefor a solution is in my eyes not strictly necessary. Having said that, I do understand people wanting support for newer bash features and GLEP54, so let's look at the possible solutions that have been proposed. Jorge Manuel B. S. Vicetto wrote: Ulrich Mueller wrote: On Sun, 17 May 2009, Denis Dupeyron wrote: 2009/5/17 Piotr Jaroszyñski pe...@gentoo.org: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I'm strongly against 1 and 2 (no need to repeat the old arguments here), but I could live with 3. Me too. My preference goes to 3 with a .eb extension and EAPI on the first line. Make this the first non-empty non-comment line. As others have commented, we should probably make this the last comment line in the header. Any suggestions for a specific identification string or do we simply use '# EAPI=X' or use a she-bang '#!/.. EAPI=X' ? In this case, I'd prefer .eb extension as well. EAPI to be somewhere near the top, I don't care that much about the exact implementation. Looks like .eb is already taken by some exotic commercial application, but I think we can ignore this. I like .eb but could also live with .gebuild as was suggested before. I'd rather go for .geb as second choice. I'd rather go shorter than longer. Robert Buchholz wrote: Judging from this list, fourth option present in the GLEP is unacceptable for you? 4. Easily fetchable EAPI inside the ebuild From what I understand, the difference between 3 and 4 is that (4) would break pre-glep55 Portage versions that see an ebuild with no metadata cache present if the ebuild uses a future EAPI that introduces changes as described in the Current behaviour section. (4) would otherwise keep the current workflow the same except restricting the way the EAPI variable is defined in the ebuild. I would argue that most people who are be exposed to repositories that do not carry a metadata cache (overlays) which use new EAPIs also keep their portage version current. I'd say go with option (4) now and by the time EAPI 4 is collected, written up, agreed upon and implemented, enough time went by so we would not have to introduce an artificial delay. And after that, there won't be any delay to avoid breakage anymore. This would still have my preference. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 1. Incompatible change of inherit (e.g. make it look in the package dir too) A case would need to be made, in my opinion, as to why we would wish to allow this in the first place. The current inherit behavior with eclasses in a central place works well enough. So I think we can disregard this. There are already horrible hacks in the tree to get per-package 'eclasses'. That's a clear sign there's something lacking. 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
Ciaran McCreesh wrote: 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. I actually like the current format in that it does *not* allow - in the version. For example, pkg-2.3.1_rc5 makes it clear that the string from 2 to rc5 is the version. If were were to allow pkg-2.3.1-rc5, this could get visually confusing (looks a bit like pkg-2.3.1-r5). In this case, *less* flexibility and more strict rules serve a good purpose, I think. -Joe
Re: [gentoo-dev] GLEP 55 updated
Ciaran McCreesh wrote: On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 1. Incompatible change of inherit (e.g. make it look in the package dir too) A case would need to be made, in my opinion, as to why we would wish to allow this in the first place. The current inherit behavior with eclasses in a central place works well enough. So I think we can disregard this. There are already horrible hacks in the tree to get per-package 'eclasses'. That's a clear sign there's something lacking. I haven't come across any horrible hacks, that I'm aware of, but of course my interest is only in certain parts of the tree. 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. Because we say so. We have chosen to do it a certain way. This works. It's uniform, it's simple, and therefor has a certain beauty to it. I see no pressing reason why we should start allowing alternative forms. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 00:08:05 +0200 Ben de Groot yng...@gentoo.org wrote: There are already horrible hacks in the tree to get per-package 'eclasses'. That's a clear sign there's something lacking. I haven't come across any horrible hacks, that I'm aware of, but of course my interest is only in certain parts of the tree. Read the glibc ebuilds sometime. Notice the 'eblits' nonsense. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. There's a difference between the clean unsupported EAPIs are treated as masked behaviour you get with EAPIs done properly, and the horrible spammy errors you get if they aren't. New global scope functions cause the latter; new EAPIs done cleanly cause only the former. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. Because we say so. We have chosen to do it a certain way. This works. It's uniform, it's simple, and therefor has a certain beauty to it. I see no pressing reason why we should start allowing alternative forms. It's an utterly arbitrary restriction. Upstreams don't standardise either way on - vs _, so there's no reason Gentoo should. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Ben de Groot yng...@gentoo.org: Ciaran McCreesh wrote: On Sun, 17 May 2009 23:17:57 +0200 Ben de Groot yng...@gentoo.org wrote: 2. Add new global scope functions in any sane way This is a valid use case, as seen by the eapi-2 update. But the way this is currently handled by portage (advising to upgrade the package manager) works. So I don't see a need to change the file extension for this reason. It means we can't start using those new global scope functions until we're sure that everyone's going to be upgraded, because users get extremely upset if they start seeing that kind of message. Isn't that a given anyway? I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure.
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009, Ciaran McCreesh wrote: Upstreams don't standardise either way on - vs _, so there's no reason Gentoo should. Upstreams use all sorts of strange versioning schemes. Here is a small collection: 1_14 - 1.14(app-emacs/limit) 1.0pre4- 1.0_pre4(app-emacs/cedet) 1.9.1-preview1 - 1.9.1_pre1 (app-emacs/ruby-mode) 2.0b6 - 2.0_beta6 (app-emacs/chess) 12B5 - 12.2.5 (dev-lang/erlang) 0.28 - 28.0(dev-lang/c-intercal, minor.major) -0.74 - ?? (SmallEiffel, negative version number) 1.-94.-2 - ?? (CLC-Intercal, negative components) We have to draw the borderline somewhere, and I think our current rules are a reasonable compromise. Ulrich
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 00:54:04 +0200 Ulrich Mueller u...@gentoo.org wrote: Upstreams don't standardise either way on - vs _, so there's no reason Gentoo should. Upstreams use all sorts of strange versioning schemes. Here is a small collection: And we can handle a lot more of them sensibly than we currently do. We can't cover everything, but of these: 1_14 - 1.14(app-emacs/limit) 1.0pre4- 1.0_pre4(app-emacs/cedet) 12B5 - 12.2.5 (dev-lang/erlang) These we should handle. 1.9.1-preview1 - 1.9.1_pre1 (app-emacs/ruby-mode) This we could handle easily if there are more things using -preview. 2.0b6 - 2.0_beta6 (app-emacs/chess) This we can't sensibly, since most people using b use it as a 'greater than' thing. 0.28 - 28.0(dev-lang/c-intercal, minor.major) -0.74 - ?? (SmallEiffel, negative version number) 1.-94.-2 - ?? (CLC-Intercal, negative components) These are upstreams being deliberately silly, so we can ignore them. We have to draw the borderline somewhere, and I think our current rules are a reasonable compromise. Forbidding -rc is not a reasonable compromise... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Sun, 17 May 2009, Ciaran McCreesh wrote: 1_14 - 1.14(app-emacs/limit) 12B5 - 12.2.5 (dev-lang/erlang) These we should handle. How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? Ulrich
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 01:11:45 +0200 Ulrich Mueller u...@gentoo.org wrote: On Sun, 17 May 2009, Ciaran McCreesh wrote: 1_14 - 1.14(app-emacs/limit) 12B5 - 12.2.5 (dev-lang/erlang) These we should handle. How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? By the time the things we need to get this done end up being accepted, we'll probably be using ranged deps, so it won't be an issue. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009, Ciaran McCreesh wrote: How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? By the time the things we need to get this done end up being accepted, we'll probably be using ranged deps, so it won't be an issue. In fact, with GLEP 54 we have the problem already now. P=foo-1a-scm could mean both of the following: PN=foo PV=1a-scm PN=foo-1a PV=scm Ulrich
Re: [gentoo-dev] GLEP 55 updated
On Mon, 18 May 2009 01:30:26 +0200 Ulrich Mueller u...@gentoo.org wrote: On Mon, 18 May 2009, Ciaran McCreesh wrote: How? Both limit-1_14 and erlang-12B5 are valid package names, so how do you determine where PN ends and where PV starts? By the time the things we need to get this done end up being accepted, we'll probably be using ranged deps, so it won't be an issue. In fact, with GLEP 54 we have the problem already now. P=foo-1a-scm could mean both of the following: PN=foo PV=1a-scm PN=foo-1a PV=scm We've had that problem ever since -100dpi things had to be made legal, and the horrible mess explaining the splitting rules in PMS came about from the last time we had this discussion. This isn't anything new -- it's just something we have to define very carefully. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 - The Long Thread
On Tue, Jun 10, 2008 at 4:51 PM, Doug Goldstein [EMAIL PROTECTED] wrote: There's a lot to be said about being stuck in the grand design mindset. I know many Gentoo, Portage, Exherbo, and Paludis developers are clearly coming to that point in their programming careers based on the comments on this thread and other threads. I would just like to caution everyone that they really need to get past this plateau in their programming careers and get on to the real mindset that matters in the future. The use case mindset. Georges Clemenceau once said : War is too serious a matter to entrust to military men. There surely is something to be said along these lines about software design and programmers. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? I remember last time I've asked this genone told me that this is not backward compatible. Ok, it's not, but what's the problem to change extension once only for this change? Call you new files like pkg-ver-eapi.emerge and that's it! What is the need to change extension every time you introduce new eapi? Another possibility is to implement this new file format and wait another one year before using it instead of crapping the tree for years with such eapi-extesions... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
On Wed, 11 Jun 2008 11:25:50 +0400 Peter Volkov [EMAIL PROTECTED] wrote: If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? a) breaks current package managers b) has no unambiguous parsing c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a lot like Debian-style foo-1.2-3 versions... I remember last time I've asked this genone told me that this is not backward compatible. Ok, it's not, but what's the problem to change extension once only for this change? It means next time we want to introduce another backward incompatible change, we have to go through the whole mess all over again. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
В Срд, 11/06/2008 в 08:34 +0100, Ciaran McCreesh пишет: On Wed, 11 Jun 2008 11:25:50 +0400 Peter Volkov [EMAIL PROTECTED] wrote: If you need eapi in file name what are the technical reasons of putting it into file name extension? Why don't you suggest better ebuild name like: pkg-ver-eapi.ebuild or pkg-eapi-ver.ebuild ? a) breaks current package managers That's why I suggested to change .ebuild extension or fix package manager now and wait another year to start using such syntax. Your answer about extension change It means next time we want to introduce another backward incompatible change, we have to go through the whole mess all over again. is not clear. What changes you have in mind? If we already have pkg, eapi and version in filename what else are you going to add there? b) has no unambiguous parsing Why? For example, just add word eapi and that it: pkg-1.2.3-eapi-1.bld. That's just an example to show that this is possible. c) looks confusing. pkg-1.2.3-1.ebuild or pkg-1-1.2.3.ebuild look a lot like Debian-style foo-1.2-3 versions... Well for me .ebuild-eapi is much more confusing. I still don't see why it's impossible to have eapi as a part of name but not in extension... -- Peter. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (why use filename extension?)
Peter Volkov wrote: Well for me .ebuild-eapi is much more confusing. I still don't see why it's impossible to have eapi as a part of name but not in extension... Although putting EAPI in the name and not the extension is *slightly* preferable to using the extension, I still do not think that it even belongs there for one main design-based reason: It does not have to be there from a design perspective. All other filename components (name-version-revision.ebuild) uniquely identify the ebuild. EAPI does not (it is meta-information only needed internally by the package manager or by someone interpretting the contents of the file). You could not have two ebuilds, for example, that have identical name/version/revision but different EAPIs - that would not make sense (and yet it would be possible if the EAPI were in the filename, causing the package manager to need rules for choosing the right ebuild to look at). The argument for putting the EAPI in the extension or filename is simply to address a particular technical implementation detail, and there are other, better, ways to solve the problem in my opinion. I would argue that GLEP 54 is also putting needless extra stuff in the filename, but we won't go there right now. :) -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 22:09:04 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Debunked according to whom? I believe that some, including you, believe you debunked them, but I do not believe there was wholesale agreement from the dev community. That doesn't really matter. Most of the dev community don't care to understand the underlying issue, so all they need to do is go along with the informed decision that the Council was supposed to have made on their behalf. By that logic (that mere ordinary devs need to be guided by their more informed elected leaders), we're doing EXACTLY what you propose. The informed decision by the Council was to defer the GLEP. As a result the lesser devs are going along with that decision and not implementing it. The fact is that most devs probably do care to understand the underlying issues. Many just happen to disagree with you. I still haven't seen a good argument as to why the EAPI can't be handled as something like a magic number. Maybe make the first line in the ebuild: #EAPI=foo ELF vs A.OUT don't use extensions to identify its files - the original file format was designed to allow file identification from the contents. The only issue I can see with putting the EAPI on the first line is with legacy package managers. That could be fixed in a number of ways. The simplest would be just allowing it to break and sending out the fix well in advance of any breakage on GMN. Considering the fiasco that we've had with some GCC/GLIBC upgrades and similar stuff in the past this would be pretty minor. A less pretty solution might be a one-time file extension change. There wouldn't be any need to repeat all of this every time the EAPI changes - at that point we've standardized the location of the EAPI within the file. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
Joe Peterson wrote: But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. If the user knows that keywords are set by the KEYWORDS variable, then she must be familiar with the EAPI. The meaning of the KEYWORDS variable is defined by the EAPI. Along those lines, as I've said before, migrating to a new extension, *one-time*, as a solution to this, although not optimal, would be far more satisfactory than introducing a series of ever-changing extensions. No it won't. It means future EAPIs will be restricted to some particular source format. I assume you mean that EAPI needs to be in the file - again, is this bad? Many file formats specify a file format version as part of the file. Sure. If current EAPI specified that a sequence of four bytes starting at offset 0x10 is a little-endian magic number that is used to identify an EAPI, that'd be all we want. However, current format definition is rather complex; there's nothing as simple as read several bytes at some offset and use them. Cheers, -jkt -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: On Mon, 9 Jun 2008 22:35:25 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Did anyone already propose specifying this in metadata.xml? Yup. That's a no-go, since metadata.xml is quite rightly treated as being not suitable for anything the package manager really needs. I think a separate file, especially one that uses a standard XML format, would be a fine place for things that the PM needs. Just because we do not use it this way now does not mean it is not a good idea. Also, the EAPI would be out-of-band and not require sourcing of the bash script to determine. It also moves the EAPI definition even further away from the ebuild, which makes it even harder to work with. Harder to work with in what way? And, of course, it's not backwards compatible, so it'd still need a file extension change. I am not convinced of this. As others have stated, portage/PM should be upgraded with the new capability well in advance of new EAPIs. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Tue, 10 Jun 2008 07:31:09 -0600 Joe Peterson [EMAIL PROTECTED] wrote: I think a separate file, especially one that uses a standard XML format, would be a fine place for things that the PM needs. XML is a pain in the ass. Just because we do not use it this way now does not mean it is not a good idea. Also, the EAPI would be out-of-band and not require sourcing of the bash script to determine. The file extension is out-of-band and yet still coupled to the individual ebuilds in an obvious way. It also moves the EAPI definition even further away from the ebuild, which makes it even harder to work with. Harder to work with in what way? It decouples the EAPI and the thing written in that EAPI. And, of course, it's not backwards compatible, so it'd still need a file extension change. I am not convinced of this. As others have stated, portage/PM should be upgraded with the new capability well in advance of new EAPIs. But that's exactly what EAPIs are there to solve. Having to wait two years (or however long Gentoo goes between releases these days) just to use simple new features slows down progress even more. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55
Jan Kundrát wrote: If the user knows that keywords are set by the KEYWORDS variable, then she must be familiar with the EAPI. The meaning of the KEYWORDS variable is defined by the EAPI. But that's not really what I find objectionable. There's no need to make EAPI so special that it alters the file extension. If EAPI is accessible as part of the file or in metadata.xml, e.g., it still serves this purpose well, and that info is exposed at the right level. Sure. If current EAPI specified that a sequence of four bytes starting at offset 0x10 is a little-endian magic number that is used to identify an EAPI, that'd be all we want. However, current format definition is rather complex; there's nothing as simple as read several bytes at some offset and use them. I would not suggest byte-level methods, no - these files are not binary. There are simple ways to parse text files to find the EAPI. If it is in the ebuild, putting it in the header (out-of-band) works. If it is in metadata, simply parsing XML works. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
On Tue, 10 Jun 2008 02:58:54 +0100 Ciaran McCreesh [EMAIL PROTECTED] wrote: Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. Except any program using .cc or .cpp for code is liable to break on gcc, as they are C++ file extensions, and to the best of my (admittedly limited knowledge) C and C++ are distinct languages... So relying on the file extension seems to be a recipe for misunderstanding. Why limit the functionality of the package manager to rely on the file names? How do you protect the package manager from a malicious ebuild masquerading under the wrong EAPI? Relying on the file name for information is the kind of design decision we laugh at in Windows, so why adopt it here? -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
On Tue, 10 Jun 2008 15:36:58 +0100 Robert Bridge [EMAIL PROTECTED] wrote: So relying on the file extension seems to be a recipe for misunderstanding. Why limit the functionality of the package manager to rely on the file names? How do you protect the package manager from a malicious ebuild masquerading under the wrong EAPI? Relying on the file name for information is the kind of design decision we laugh at in Windows, so why adopt it here? There is no protection against malicious ebuilds. Malicious ebuilds already run code as root when you install them. Being able to get an ebuild run with the wrong EAPI is utterly irrelevant. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 - The Long Thread
On Tue, 10 Jun 2008 10:51:39 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: I urge you all to sit down and hammer out real use case situations instead of the idealistic foo/bar/baz concepts. The use cases are stated rather clearly in the GLEP, which you clearly didn't bother to read... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] GLEP 55 - The Long Thread
Since there's so many places to comment and I have no intention of hitting all these areas, I'll just create a new thread. There's a lot to be said about being stuck in the grand design mindset. I know many Gentoo, Portage, Exherbo, and Paludis developers are clearly coming to that point in their programming careers based on the comments on this thread and other threads. I would just like to caution everyone that they really need to get past this plateau in their programming careers and get on to the real mindset that matters in the future. The use case mindset. I urge you all to sit down and hammer out real use case situations instead of the idealistic foo/bar/baz concepts. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 - The Long Thread
Ciaran McCreesh wrote: On Tue, 10 Jun 2008 10:51:39 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: I urge you all to sit down and hammer out real use case situations instead of the idealistic foo/bar/baz concepts. The use cases are stated rather clearly in the GLEP, which you clearly didn't bother to read... Concrete use cases instead of idealistic ones... -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55 - The Long Thread
On Tue, 10 Jun 2008 15:43:55 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: The use cases are stated rather clearly in the GLEP, which you clearly didn't bother to read... Concrete use cases instead of idealistic ones... What, new global scope functions is insufficiently concrete? New global scope functions to replace versionator with something on the package manager side. New global scope functions to allow per-cat/pkg eclasses. Take your pick. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
[EMAIL PROTECTED] wrote: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward), when things like SLOT, EAPI, etc., etc., seem to naturally belong as part of the script contents/syntax. Okay... so: find /usr/portage -name *ebuild becomes: find /usr/portage -name *ebuild* That doesn't seem that much harder to me... Same for the file detection for editors. I'm not saying it's a lot harder. But it is more complex and less elegant. Also, it is error-prone. If someone, by habit, looks for all *.ebuild, he will miss a portion of the ebuilds and not even realize it at first (or ever). 2) Having the same info in more than one place is generally a bad idea in any design - this is true in any discipline. [...] If you read the proposal more closely, you would notice that it specifically says to *not* specify EAPI in more than one place. It belongs solely in the filename suffix. The only reason the EAPI variable would be recognized inside the file itself is to allow for backwards compatibility with the current way EAPI=1 is done -- this behavior would be discouraged in all future ebuilds. Still, the GLEP addresses the very point of what logic has to be followed if the EAPI exists in the filename, in the file, or both. It talks of pre-source EAPIs and post-source EAPIs. Complicated. 3) It uses the extension in a way that goes against common use in computers, especially *nix. No longer could we then say that a file of type Gentoo ebuild has the extension ebuild (simple/straightforward/standard). In most unixes, the file extension is completely meaningless. What matters is the contents of the file. Nautilus, etc, mostly use detection based upon the files contents to identify file types (at least for local files), not file extensoins. That wasn't the point I was trying to make. I am not saying that the extension has special meaning (even the . has no meaning, really, in unix) to software. I mean that people associate certain types of files with certain extensions. I'm speaking more of the human interface here. 4) It seems that the motivation for this GLEP is so that the tools can determine the EAPI without reading/sourcing the script. In order to get around this, the GLEP suggests exposing this technical information in the filename. This is the wrong place to expose it, and the reasons given are not that this detail should be exposed there but rather because it is inefficient to source the file to get the info. So this is a case of trying to solve a technical issue by changing the interface. I believe it would be more correct to attack the technical problem in a way that does not do this, and I am sure this can be solved. The reason for this is that, while the current two EAPIs don't cause trouble if you try to source them when you don't support them, that doesn't mean future ones won't. I'm not talking about anything silly like rewriting ebuilds in python, but things like changing syntax for DEPEND could potentially confuse older package managers. By adding the EAPI specification to the filename instead, old package managers just plain won't see packages they don't understand, so there's no need to worry about this. Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. Also, sourcing a package to extract one metadata key takes much more time than just not loading it in the first place. I understand there are technical/performance issues to solve, but this does not, IMHO, justify moving this info into a filename/extension. 1) Littering the filename with this kind of stuff is potentially confusing to both devs and users - I know it's been stated that users shouldn't care, but I don't think that's a good reason/assumption. New eapis aren't necessarily of any immediate use to people. Those who don't see the need for them can continue to just use EAPI=0, plain old .ebuild files of the sort that've been around for years, and for many packages this is totally appropriate. The only devs who should care are the ones who have a need for the new features. But when they do need the new features, they need to use the new EAPIs. This is not a matter of degree - it is a matter of defining the filename format.
Re: [gentoo-dev] GLEP 55 (was: A few questions to our nominees)
On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: I'm not saying it's a lot harder. But it is more complex and less elegant. Also, it is error-prone. If someone, by habit, looks for all *.ebuild, he will miss a portion of the ebuilds and not even realize it at first (or ever). Yes, if something changes, and people carry on doing the old thing by habit, then things go wrong. Still, the GLEP addresses the very point of what logic has to be followed if the EAPI exists in the filename, in the file, or both. It talks of pre-source EAPIs and post-source EAPIs. Complicated. And if the GLEP didn't address it people would complain that it allowed undefined behaviour. Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Along those lines, as I've said before, migrating to a new extension, *one-time*, as a solution to this, although not optimal, would be far more satisfactory than introducing a series of ever-changing extensions. No it won't. It means future EAPIs will be restricted to some particular source format. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: I'm not saying it's a lot harder. But it is more complex and less elegant. Also, it is error-prone. If someone, by habit, looks for all *.ebuild, he will miss a portion of the ebuilds and not even realize it at first (or ever). Yes, if something changes, and people carry on doing the old thing by habit, then things go wrong. Yes, if everyone is perfect and remembers to do things perfectly right, there would never be issues in many things, but when you make something more complicated, there will be more errors. Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. No, I get that. But once you develop the concept of an EAPI, the very next package manager version can be aware of it and check the EAPI of an ebuild. If the ebuild specifies none, then it is old-style. If it specifies one that is unknown or newer than what that package manager version knows it can handle, it can handle that case (ignore it or whatever). I don't see why you need to keep bumping the filename/extension every time it changes from that point forward. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. Along those lines, as I've said before, migrating to a new extension, *one-time*, as a solution to this, although not optimal, would be far more satisfactory than introducing a series of ever-changing extensions. No it won't. It means future EAPIs will be restricted to some particular source format. I assume you mean that EAPI needs to be in the file - again, is this bad? Many file formats specify a file format version as part of the file. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 09 Jun 2008 20:15:56 -0600
Joe Peterson [EMAIL PROTECTED] wrote:
Yes, if everyone is perfect and remembers to do things perfectly
right, there would never be issues in many things, but when you make
something more complicated, there will be more errors.
So we shouldn't ever change anything?
Which is why programs that use any major C feature introduced since
1980 use the extension '.cc' or '.cpp'.
So why would not a one-time new extension (e.g. .eb) do the trick,
just like .cc works for C programs? Unless you are talking about
needing to specify the EAPI in the file if the more advanced features
are to be used, but I see nothing wrong with that requirement - it's
not much different than specifying a slot, keywords, whatever.
Because then we won't be able to change source compatibility again in
the future without introducing yet another new extension.
You completely miss the point of the GLEP. We need new extensions
precisely because current package managers can't handle future EAPIs
cleanly, and we need to carry on using new extensions because
otherwise we restrict what future EAPIs can do.
No, I get that. But once you develop the concept of an EAPI, the very
next package manager version can be aware of it and check the EAPI of
an ebuild. If the ebuild specifies none, then it is old-style. If it
specifies one that is unknown or newer than what that package manager
version knows it can handle, it can handle that case (ignore it or
whatever). I don't see why you need to keep bumping the
filename/extension every time it changes from that point forward.
Because the package manager doesn't know how to extract the EAPI from
ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild
might look like this:
require mypackage using ANIMAL=monkey
How do current package managers understand that the EAPI there is 2?
But what users *really* don't care about is EAPIs, and this GLEP
would expose that technical detail to them in a very blatent way.
Anyone who cares about ebuilds at a file level has to care about
EAPIs.
Not really. A typical user does not need to know about EAPIs at all,
but he might want to peruse the portage tree to look for ebuilds. He
might also want to grep for KEYWORDS or whatever. The user can delve
into it as much as needed or desired, but if there are these
mysterious EAPI numbers tacked onto the extensions, then it's an
added complication that is not important to all users.
The typical user should be using a tool to query that sort of thing.
Along those lines, as I've said before, migrating to a new
extension, *one-time*, as a solution to this, although not
optimal, would be far more satisfactory than introducing a series
of ever-changing extensions.
No it won't. It means future EAPIs will be restricted to some
particular source format.
I assume you mean that EAPI needs to be in the file - again, is this
bad? Many file formats specify a file format version as part of the
file.
It's a pain in the ass, because it means no introducing new global
scope functions and no changing behaviour of existing global scope
functions.
Most file formats don't have to deal with the compatibility issues that
we do. For example, try feeding this C++ program to a C++0x compiler:
void foo(int x)
{
auto bool requires(x == 1);
}
Or this C++0x program to a C++ compiler:
template std::Regular T_
T__ foo(T_ x)
{
std::liststd::listT_ l;
return x;
}
In both cases, you get user visible messy errors. That's not something
we have the luxury of being able to do.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: On Mon, 09 Jun 2008 20:15:56 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Yes, if everyone is perfect and remembers to do things perfectly right, there would never be issues in many things, but when you make something more complicated, there will be more errors. So we shouldn't ever change anything? Of course I don't mean that. But humans and computers are each good at a complementary set of things. Computers handle obscure complexity easily; humans do not, so it's better to let computers make our lives easier rather than the reverse when designing systems. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because then we won't be able to change source compatibility again in the future without introducing yet another new extension. But GLEP 55 is suggesting exactly that: yet another extension for each new EAPI (I know it is defines this as .ebuild-EAPI, but that is just semantics). Source compatibility is not an issue once the EAPI syntax in the file is defined and the package manager starts to recognize it. At that point it can handle the ebuild at whatever EAPI the ebuild declares. It is only the older unaware version of the package manager that would get confused, but that would be solved by a one-time extension change: the old one would not even look for the new (e.g.) .eb extension (only the old .ebuild one), which is exactly what GLEP 55 tries to address. But the extension change is only needed once. Once the EAPI syntax is introduced and the package manager has code to read it, the package manager is able to determine the EAPI for all future EAPIs. If some new syntax in an as-yet unsupported EAPI exists, the EAPI-version-aware package manager will not trip on it, since it can just not bother to deal with future EAPI ebuilds. Now, even if there is no extension change, if we wait long enough, the chances of an old machine stubbornly staying at an old (pre-EAPI-aware) portage version gets slimmer and slimmer. So I'm not even sure this one-time extension change is really mandatory. But if it is determined to be so, I still don't see why we need endless extension changes as suggested in GLEP 55. Because the package manager doesn't know how to extract the EAPI from ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild might look like this: require mypackage using ANIMAL=monkey How do current package managers understand that the EAPI there is 2? The old (non-aware) package manager version would not, and yes, it would fail. So there are two alternatives: wait long enough or do a one-time extension change. In the latter case, the package manager would not even see the new files. But the new package manager versions would determine the EAPI from a defined syntax and ignore ebuilds with future EAPIs. And I do understand the issue of sourcing, since ebuilds are bash. If sourcing is an issue (and I'm not sure it is an overriding one - that's a good discussion), I would suggest an out-of-band EAPI specifier, but not in the filename. Put it in a comment line in the header, like: # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ # EAPI=2 inherit eutils ... So, the first non-blank and non-'#' line (in this case, inherit ...) would signify the end of the search for the EAPI= string, making parsing trivial. Therefore, the only rule would have to be that EAPI= needs to be in a header comment. Other rules could be that it needs to be the only thing on such a header line - whatever. Again, these are technical details, and I think we can all put our heads together to come up with the best way to do it. If sourcing is a better way to go (i.e. to allow EAPI= to be anywhere in the file with no comment char), caching it might be the answer. How to make this efficient would become an implementation detail. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. The typical user should be using a tool to query that sort of thing. Sure, but my point is: some users *will* want to explore - why not
Re: [gentoo-dev] GLEP 55
Joe Peterson schrieb: Ciaran McCreesh wrote: On Mon, 09 Jun 2008 19:49:08 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Well, in general, if you rely on extensions changing every time a program cannot deal with a new feature of a file format, it would be quite crazy. For example, if C programs had to start using .c-2, .c-3, etc., it would get ugly fast. Which is why programs that use any major C feature introduced since 1980 use the extension '.cc' or '.cpp'. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because that is about the same damage (file ext. changes, people might get confused etc.) with less capabilities. Also, it is easy to build EAPI checking into portage now, and when the requisite time passes, you only need to deal with situations where *very* old portage versions are still in use. Since portage is typically the first thing the system upgrades after a sync, I don't see a big issue. Or, if that is not acceptable, see my comment at the end about a one-time change to a new extension like .eb. You completely miss the point of the GLEP. We need new extensions precisely because current package managers can't handle future EAPIs cleanly, and we need to carry on using new extensions because otherwise we restrict what future EAPIs can do. No, I get that. But once you develop the concept of an EAPI, the very next package manager version can be aware of it and check the EAPI of an ebuild. If the ebuild specifies none, then it is old-style. If it specifies one that is unknown or newer than what that package manager version knows it can handle, it can handle that case (ignore it or whatever). I don't see why you need to keep bumping the filename/extension every time it changes from that point forward. Because you can change the EAPI in a way that that may not work anymore. Specifying the EAPI outside the actual ebuild is more flexible. It doesn't have to be the file extension, but that is the obvious solution. But what users *really* don't care about is EAPIs, and this GLEP would expose that technical detail to them in a very blatent way. Anyone who cares about ebuilds at a file level has to care about EAPIs. Not really. A typical user does not need to know about EAPIs at all, but he might want to peruse the portage tree to look for ebuilds. He might also want to grep for KEYWORDS or whatever. The user can delve into it as much as needed or desired, but if there are these mysterious EAPI numbers tacked onto the extensions, then it's an added complication that is not important to all users. No, not really. If you have .txt, .txt-2, .text or .footext in a dir, you would still realize, that those should be text files. Of course, a future EAPI could be named .whatevercomestoyourmind, but first, you can expect people to be smart enough to not do that and second, you can still identify the packages, because they are still named foo-version.whatevercomestoyourmind. Bernd -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 09 Jun 2008 21:36:24 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Of course I don't mean that. But humans and computers are each good at a complementary set of things. Computers handle obscure complexity easily; humans do not, so it's better to let computers make our lives easier rather than the reverse when designing systems. And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. So why would not a one-time new extension (e.g. .eb) do the trick, just like .cc works for C programs? Unless you are talking about needing to specify the EAPI in the file if the more advanced features are to be used, but I see nothing wrong with that requirement - it's not much different than specifying a slot, keywords, whatever. Because then we won't be able to change source compatibility again in the future without introducing yet another new extension. But GLEP 55 is suggesting exactly that: yet another extension for each new EAPI (I know it is defines this as .ebuild-EAPI, but that is just semantics). GLEP 55 suggests a backwards compatible, forwards compatible way of dealing with the problem that doesn't involve adding new sets of rules every few EAPIs. Source compatibility is not an issue once the EAPI syntax in the file is defined and the package manager starts to recognize it. At that point it can handle the ebuild at whatever EAPI the ebuild declares. No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. It is only the older unaware version of the package manager that would get confused, but that would be solved by a one-time extension change: the old one would not even look for the new (e.g.) .eb extension (only the old .ebuild one), which is exactly what GLEP 55 tries to address. But the extension change is only needed once. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. Once the EAPI syntax is introduced and the package manager has code to read it, the package manager is able to determine the EAPI for all future EAPIs. Which means we can't change anything useful in future EAPIs. Which, funnily enough, is what the GLEP is designed to solve. Now, even if there is no extension change, if we wait long enough, the chances of an old machine stubbornly staying at an old (pre-EAPI-aware) portage version gets slimmer and slimmer. So I'm not even sure this one-time extension change is really mandatory. Except it is, because current EAPI aware package managers still can't deal with global scope changes. Because the package manager doesn't know how to extract the EAPI from ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild might look like this: require mypackage using ANIMAL=monkey How do current package managers understand that the EAPI there is 2? The old (non-aware) package manager version would not, and yes, it would fail. So there are two alternatives: wait long enough or do a one-time extension change. In the latter case, the package manager would not even see the new files. But the new package manager versions would determine the EAPI from a defined syntax and ignore ebuilds with future EAPIs. And then how do we deal with EAPI 3, where the syntax changes again? And I do understand the issue of sourcing, since ebuilds are bash. If sourcing is an issue (and I'm not sure it is an overriding one - that's a good discussion), I would suggest an out-of-band EAPI specifier, but not in the filename. Put it in a comment line in the header, like: # Copyright 1999-2008 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: /var/cvsroot/gentoo-x86/sys-fs/btrfs-...$ # EAPI=2 Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. Again, these are technical details, and I think we can all put our heads together to come up with the best way to do it. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. The typical user should be using a tool to query that sort of thing. Sure, but my point is: some users *will* want to explore - why not encourage this? And if so, why not make the conventions used as clean and understandable (and elegant) as possible without added noise from details that do not belong at that (e.g. the filename) level? And when they do explore, they learn straight away what EAPI is. Gentoo is a technical distro, and we encourage users to get technical in every other way. Saying that they should remain at the portage interface level is not consistent with that philosophy. And users who get technical knowing what EAPI is is a good thing. Right: there
Re: [gentoo-dev] GLEP 55
Ciaran McCreesh wrote: And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. I disagree. One is exposed to devs only as ebuild syntax; the other is exposed in an inappropriate location to everyone looking at the portage tree. No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. Doing it out-of-band solve this. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. Huh? If the new portage knows how to determine the EAPI definitively (and that would be defined), it can deal with the differences. And then how do we deal with EAPI 3, where the syntax changes again? Portage (or whatever PM) reads the EAPI, determines it is 3, and goes from there. If you change the way you declare EAPI each time, yeah, that's a problem, but I'm not sure why that would ne necessary. Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. Massive? Simply a one-line EAPI declaration is not massive nor complex. And is more elegant than putting it in the filename. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. Debunked according to whom? I believe that some, including you, believe you debunked them, but I do not believe there was wholesale agreement from the dev community. We had that discussion when the GLEP was first proposed. Yes, but nothing was decided, and agreement was not reached. I'd be very surprized if I were the only one here who is not entirely satisfied with GLEP 55's solution to this. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 09 Jun 2008 22:09:04 -0600 Joe Peterson [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: And a file extension is far less obscurely complex than enforcing arbitrary syntax restrictions upon ebuilds. I disagree. One is exposed to devs only as ebuild syntax; the other is exposed in an inappropriate location to everyone looking at the portage tree. You might as well say We should get rid of Manifest because anyone looking at the tree is exposed to security internals... No it can't. EAPI has to be known before the source can start. Bash doesn't provide traps for executing code upon changed variables. Doing it out-of-band solve this. Doing it out-of-band but in-the-file means the file format is fixed in annoying ways. No, it's only needed once per non-trivial change. So we might as well just change it for every EAPI. Huh? If the new portage knows how to determine the EAPI definitively (and that would be defined), it can deal with the differences. Sure, until there's another format change. Then we need yet another new extension. What will we use then? '.ebld'? The EAPI-in-extension format is cheap. People have been using it for character sets and languages for decades. And then how do we deal with EAPI 3, where the syntax changes again? Portage (or whatever PM) reads the EAPI, determines it is 3, and goes from there. If you change the way you declare EAPI each time, yeah, that's a problem, but I'm not sure why that would ne necessary. But you're not sure that it's not necessary, so why impose entirely pointless restrictions that everyone in the future has to stick by? Which is way more obscure, complex and arbitrary than a file extension change. And it still imposes massive restrictions upon future EAPIs. Massive? Simply a one-line EAPI declaration is not massive nor complex. And is more elegant than putting it in the filename. You're suddenly imposing restrictions upon the content of comments, and requiring a whole new parser to deal with it. The point of comments is that they're ignored. Every issue you've raised so far was already discussed and debunked the first time this discussion happened. Please read the original discussions before continuing. Debunked according to whom? I believe that some, including you, believe you debunked them, but I do not believe there was wholesale agreement from the dev community. That doesn't really matter. Most of the dev community don't care to understand the underlying issue, so all they need to do is go along with the informed decision that the Council was supposed to have made on their behalf. We had that discussion when the GLEP was first proposed. Yes, but nothing was decided, and agreement was not reached. I'd be very surprized if I were the only one here who is not entirely satisfied with GLEP 55's solution to this. Yet GLEP 55 is the only solution that's been proposed that solves the requirements. And your entire argument boils down to file extension changes don't look pretty, for some arbitrary value of pretty that also precludes index.html.en and index.html.utf-8. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP 55
On 05:20 Tue 10 Jun , Ciaran McCreesh wrote: Yet GLEP 55 is the only solution that's been proposed that solves the requirements. And your entire argument boils down to file extension changes don't look pretty, for some arbitrary value of pretty that also precludes index.html.en and index.html.utf-8. Did anyone already propose specifying this in metadata.xml? Clearly one downside is that PMs would need to be able to parse it to do anything, but that would also enable us to do a lot more with metadata.xml that we currently don't because we can't have PMs rely on it. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 55
On Mon, 9 Jun 2008 22:35:25 -0700 Donnie Berkholz [EMAIL PROTECTED] wrote: Did anyone already propose specifying this in metadata.xml? Yup. That's a no-go, since metadata.xml is quite rightly treated as being not suitable for anything the package manager really needs. It also moves the EAPI definition even further away from the ebuild, which makes it even harder to work with. And, of course, it's not backwards compatible, so it'd still need a file extension change. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszyński wrote: The package manger would have to look for ebuilds in the main dir and all the subdirs in case it doesn't have/can't use the cache. No, it would have to check only for subdirectories named after known and supported EAPIs. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Sat, Dec 22, 2007 at 07:09:30AM +, Ciaran McCreesh wrote:
On Sat, 22 Dec 2007 03:41:02 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Piotr Jaroszyński kirjoitti:
This GLEP proposes usage of EAPI-suffixed file extensions for
ebuilds (for example, foo-1.2.3.ebuild-1).
It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file
names.
example:
${PORTDIR}/category/pkg/eapiX/
In terms of what it does and doesn't allow, this one's equivalent. But
it has some new disadvantages:
* It's several more directory reads. This is a measurable performance
hit on something that's already i/o bound.
Among other things, because readdirs cannot be neither readahead nor
'advised'. Which is STUPIDLY slow. So adding yet another directory to
the hierarchy is quite silly.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgp2k93LGjnu1.pgp
Description: PGP signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Saturday 22 of December 2007 10:50:40 Jan Kundrát wrote: Piotr Jaroszyński wrote: The package manger would have to look for ebuilds in the main dir and all the subdirs in case it doesn't have/can't use the cache. No, it would have to check only for subdirectories named after known and supported EAPIs. Not really, we still want to show ebuilds with unsupported EAPI as being masked, but I agree it will have to check only eapiX subdirs. It's still a performance hit though. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszyński kirjoitti:
This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for
example, foo-1.2.3.ebuild-1).
It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file names.
example:
${PORTDIR}/category/pkg/eapiX/
Regards,
Petteri
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Saturday 22 of December 2007 02:41:02 Petteri Räty wrote: Piotr Jaroszyński kirjoitti: This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). It seems many people don't like the idea of having it in the filename Seems you are counting the posts, not the people. but how about having subdirectories for different eapis. This should even be faster for the package manager as it can just ignore the directories it can't understand instead of having to parse the file names. It was already proposed, but didn't seem to get much support. It is equivalent to using the suffixes, but I see it rather as perfomarnce hit, not improvement. The package manger would have to look for ebuilds in the main dir and all the subdirs in case it doesn't have/can't use the cache. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Sat, 22 Dec 2007 03:41:02 +0200
Petteri Räty [EMAIL PROTECTED] wrote:
Piotr Jaroszyński kirjoitti:
This GLEP proposes usage of EAPI-suffixed file extensions for
ebuilds (for example, foo-1.2.3.ebuild-1).
It seems many people don't like the idea of having it in the filename
but how about having subdirectories for different eapis. This should
even be faster for the package manager as it can just ignore the
directories it can't understand instead of having to parse the file
names.
example:
${PORTDIR}/category/pkg/eapiX/
In terms of what it does and doesn't allow, this one's equivalent. But
it has some new disadvantages:
* It's several more directory reads. This is a measurable performance
hit on something that's already i/o bound.
* It's harder to work with for developers. Ebuilds are no longer all in
the same place, and it's harder to see what you're working with.
On a subjective niceness scale, I'd suspect that the file extension is
less unnice.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
