[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 19 Dec 2007 00:06:53 +: And if a particular ebuild uses features from a non-conflicting super-set of several such EAPIs (Ulrich's message) ... Then there should be an EAPI defined that permits all of those features. Functionality would only be removed from EAPIs for specific reasons: * Conflicts with new features (think *DEPEND vs DEPENDENCIES). In which case, you can't mix features between EAPIs anyway. * Deprecating old nasty features. In which case, you shouldn't be using said features anyway. * Massively different EAPIs. In which case you rellly can't mix EAPIs. I thought it worthwhile when I saw the question asked, but given your experience in the matter and the lack of anyone from the other PMs saying otherwise, I'll take your word for it. Thanks. (Of course I can't/don't speak for the original question poster.) (BTW, saw the http://obsethryl.eu interview. While I'm probably part of the noise, someone with the demonstrated tenacity to follow thru as you do... every comment gets a reply... that deserves and gets a lot of respect, in my book. Thanks /for/ that follow-thru.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote:
Why can't it be in the file but readable without sourcing?
There's _no_ need to source, nor constrain like that, for a simple
one-line variable, eg:
$ sed -nr '/^[[:space:]]*DESCRIPTION=([^]*).*/ { s//\1/p;q; }' \
app-portage/autounmask/autounmask-0.21.ebuild
autounmask - Unmasking packages the easy way
eapi=$(sed -nr '/^[[:space:]]*EAPI=([^]*).*/ { s//\1/p;q; }'
foo.ebuild)
[[ $eapi ]] checkAPI $eapi
..would do it in bash (empty if unset in ebuild) assuming the
conventional EAPI=xx format is used. Other languages can call system()
easily enough.
This is just *brillant*. Lets see how useful your solution is:
--- 8 ---
# EAPI has to be set differently based upon tests on PV
Er, why exactly? Why not just have the new version of the ebuild declare a
new EAPI?
if [[ -z ${PV/?.?/} ]] ; then
EAPI=bar-1
elif [[ -z ${PV/?.?.?/} ]] ; then
EAPI=0
else
EAPI=1
fi
--- 8 ---
So please, no hacks.
Are you really telling me you are going to write _one_ ebuild with /that/
god-awful hackery in it?
If a new version of an ebuild uses a different EAPI, one would have thought
the changes to it-- to use that EAPI-- would mean a single EAPI declaration
is enough.
Sticking to a single EAPI=xx format in the ebuild means we don't have the
*hack* of duplicating information in the filename (and the whole
{pre,post}src issue, QA checks for human error since this is redundant
info) simply to avoid parsing a config file.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 08:12:24 +0100 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: You're done as long as ebuilds are written in bash. Not even that. What if people decide that rather than writing EAPI=blah, eapi blah is cleaner? What if metadata is moved out of the ebuild, as some people started doing years ago? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 10:26:16 +
Steve Long [EMAIL PROTECTED] wrote:
Are you really telling me you are going to write _one_ ebuild
with /that/ god-awful hackery in it?
Are you really suggesting that no-one ever will?
Sticking to a single EAPI=xx format in the ebuild means we don't
have the *hack* of duplicating information in the filename (and the
whole {pre,post}src issue, QA checks for human error since this is
redundant info) simply to avoid parsing a config file.
There is no duplication of information, nor redundancy.
The pre/post source issue exists regardless of how EAPI is set -- it's
just that with filename EAPIs, you aren't restricted to post source
changes. It's explicit in the GLEP because it's important that package
mangers get it right, but it's not a new issue.
Ebuilds are not config files.
Really. It's a heck of a lot cleaner in the filename suffix.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote:
On Wed, 19 Dec 2007 10:26:16 +
Steve Long [EMAIL PROTECTED] wrote:
Are you really telling me you are going to write _one_ ebuild
with /that/ god-awful hackery in it?
Are you really suggesting that no-one ever will?
They won't if the spec and the docs say it's restricted to a single
instance, which can be checked trivially by repoman. The example given was
contrived and not at all representative imo; for instance one could as
easily do the same kind of thing with DESCRIPTION, but it would be of
little use and just add confusion to no purpose.
Sticking to a single EAPI=xx format in the ebuild means we don't
have the *hack* of duplicating information in the filename (and the
whole {pre,post}src issue, QA checks for human error since this is
redundant info) simply to avoid parsing a config file.
There is no duplication of information, nor redundancy.
So what were the QA checks you mentioned to confirm that the same EAPI is
set in both the filename and the ebuild, for-- if not integrity of
duplicated data?
The pre/post source issue exists regardless of how EAPI is set -- it's
just that with filename EAPIs, you aren't restricted to post source
changes.
And what benefit does that provide, besides making it easier for your
package manager?
(I note this is a technical consideration of the implementation, given as a
reason to change a clean API-- with consequences for workflow.)
It's explicit in the GLEP because it's important that package
mangers get it right, but it's not a new issue.
Sure.
Ebuilds are not config files.
Indeed not, but they can be parsed as such for simple, core, metadata.
Really. It's a heck of a lot cleaner in the filename suffix.
Nah, it's an awful hack and you know it. It has nothing to do with package
naming and is unnecessary exposure of internal data. -rN is ok, and there
are rules on when and when not to bump rev; this is not. It's much cleaner
specified as part of the ebuild in the same way as DESCRIPTION, so long as
it is only specified once.
Or do you see some real benefit to specifying EAPI more than once as in the
example? If so, please share it.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 00:07:22 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Tue, 18 Dec 2007 16:45:01 +0100 Marius Mauch [EMAIL PROTECTED] wrote: There is one significant problem not covered in the GLEP: If a package contains an ebuild with a suffixed extension then all developers ever working on that _package_ must use tools that can handle such ebuilds, otherwise there will likely be problems regarding the Manifest handling due to misclassifications of the file extension. This isn't a new requirement introduced by the GLEP. That's already the case with EAPI things. Partially correct. The difference is that the data that the compability check is completely different, so while the requirement of using compatible tools might already exist it's worth to spell out the new meaning of compability. The potential impact is another change, currently if tools couldn't handle specific ebuilds with specific EAPIs they would not (silently) generate wrong data in the Manifest. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Tue, 18 Dec 2007 21:38:08 +0100 Fabian Groffen [EMAIL PROTECTED] wrote: Just to have it spelt out, what you suggest here is that EAPI has a single value, a word or a number, that refers to a set of features and rules, if I understand correctly. With this way of using EAPI I fail to see why EAPIs aren't orderable. Even with the example you gave in the previous mail, it looks like a perfect succession of EAPIs. It doesn't *have* to be a perfect succession. It's entirely possible that there will be, say, two divergent EAPI branches or even that there will be a completely unrelated new EAPI format. What's the point in having such thing? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wednesday 19 of December 2007 15:27:07 Luca Barbato wrote: Fernando J. Pereda wrote: On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote: 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 3 8 4' (and that example uses no odd chars beyond the EAPI component space separator)? This is talking about something not covered by this GLEP so what is your point? I think the glep should try to address this concern... Mixing EAPIs can't work. Strange chars shouldn't be allowed for obvious reasons, [A-Za-z0-9+_-] would be fine by me. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński wrote: Hello, attaching the GLEP. most current version: http://dev.gentoo.org/~peper/glep-0055.html http://dev.gentoo.org/~peper/glep-0055.txt How would it be different than having EAPI=string put in a defined position of the file? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: On Tue, Dec 18, 2007 at 07:45:44PM +, Duncan wrote: Fernando J. Pereda [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007 18:56:32 +0100: And as we have now learned that EAPI strings are not limited to digits (see ciaranm's message) and may even contain blanks (see grobian's message), we would have ebuilds with very strange filenames. What's the problem with this? 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1' (note the space) anyone? I know what filenames with spaces mean, thank you very much. How about when we have a dozen or so EAPIs active, several of which apply to a specific ebuild? 'app-shells/bash-3.2_p17-r1.ebuild-prefix 1 2 foo zork bar baz fa querty 3 8 4' (and that example uses no odd chars beyond the EAPI component space separator)? This is talking about something not covered by this GLEP so what is your point? I think the glep should try to address this concern... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? I'm afraid that before proposing that we could go back thinking about which is the usage of EAPI. Is the a concise and clear text about it already? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote: How would it be different than having EAPI=string put in a defined position of the file? We wouldn't be able to take advantage of this GLEP for a year or so. But even putting that aside I still prefer the filename approach for its unambiguity. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński wrote: On Wednesday 19 of December 2007 15:37:44 Luca Barbato wrote: How would it be different than having EAPI=string put in a defined position of the file? We wouldn't be able to take advantage of this GLEP for a year or so. I don't see why, articulate. But even putting that aside I still prefer the filename approach for its unambiguity. Again you aren't telling which is the ambiguity. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote: Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? Because EAPIs can define colliding features. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp90C5dzn9AZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote: Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? Because EAPIs can define colliding features. The sense I've gotten from this discussion so far is that if you want features from two EAPIs you know *can* be combined without collisions, you should define a third EAPI that is a superset of the other 2. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato [EMAIL PROTECTED] wrote: How would it be different than having EAPI=string put in a defined position of the file? It's not - It is just defining that position to be in the name of the file instead of the contents :) -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm) signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote: Fernando J. Pereda [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 04:17:21PM +0100, Luca Barbato wrote: Piotr Jaroszyński wrote: Mixing EAPIs can't work. Why? Because EAPIs can define colliding features. The sense I've gotten from this discussion so far is that if you want features from two EAPIs you know *can* be combined without collisions, you should define a third EAPI that is a superset of the other 2. *nod* But that is different from arbitrary mixing them, which is what originated this subthread. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpVgdhCxzpDI.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Steve Long wrote: Ciaran McCreesh wrote: There is no duplication of information, nor redundancy. So what were the QA checks you mentioned to confirm that the same EAPI is set in both the filename and the ebuild, for-- if not integrity of duplicated data? +1 Really. It's a heck of a lot cleaner in the filename suffix. Nah, it's an awful hack and you know it. It has nothing to do with package naming and is unnecessary exposure of internal data. Yes! Thank you, Steve! -Joe -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 11:05:35 +
Steve Long [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
On Wed, 19 Dec 2007 10:26:16 +
Steve Long [EMAIL PROTECTED] wrote:
Are you really telling me you are going to write _one_ ebuild
with /that/ god-awful hackery in it?
Are you really suggesting that no-one ever will?
They won't if the spec and the docs say it's restricted to a single
instance, which can be checked trivially by repoman. The example
given was contrived and not at all representative imo; for instance
one could as easily do the same kind of thing with DESCRIPTION, but
it would be of little use and just add confusion to no purpose.
Except people *do* have generated DESCRIPTION etc, and with good
reason. A simple example is the vim-spell-* packages.
Sticking to a single EAPI=xx format in the ebuild means we don't
have the *hack* of duplicating information in the filename (and the
whole {pre,post}src issue, QA checks for human error since this is
redundant info) simply to avoid parsing a config file.
There is no duplication of information, nor redundancy.
So what were the QA checks you mentioned to confirm that the same
EAPI is set in both the filename and the ebuild, for-- if not
integrity of duplicated data?
It's to catch developers screwing up an unnecessarily specifying EAPI
manually. For example, someone might copy an EAPI 1 ebuild to
a .ebuild-2. But the only time that will happen is when there's a
screwup.
The pre/post source issue exists regardless of how EAPI is set --
it's just that with filename EAPIs, you aren't restricted to post
source changes.
And what benefit does that provide, besides making it easier for your
package manager?
It's not a question of ease. It's a question of being possible. You
need to understand the metadata generation process to understand why
the package manger has to assume a particular EAPI when generating the
metadata. Without the EAPI in the suffix, the assumed EAPI has to be
some weird combination of all existing and all possible future EAPIs --
which isn't logically sound.
(I note this is a technical consideration of the implementation,
given as a reason to change a clean API-- with consequences for
workflow.)
No no. It's already an ebuild-visible issue, and there's no way it
can't be that doesn't involve imposing restrictions upon every single
possible future EAPI.
Ebuilds are not config files.
Indeed not, but they can be parsed as such for simple, core, metadata.
There is currently no information available from an ebuild that can be
parsed by any tool other than bash.
Really. It's a heck of a lot cleaner in the filename suffix.
Nah, it's an awful hack and you know it. It has nothing to do with
package naming and is unnecessary exposure of internal data. -rN is
ok, and there are rules on when and when not to bump rev; this is
not. It's much cleaner specified as part of the ebuild in the same
way as DESCRIPTION, so long as it is only specified once.
Or do you see some real benefit to specifying EAPI more than once as
in the example? If so, please share it.
And again, you show that you don't understand what's going on. EAPI is
only specified once except where developers screw up. The GLEP merely
moves the EAPI to being set *before* the metadata is generated, which
removes all the restrictions that having EAPI as part of the ebuild's
content imposes.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 15:18:28 +0100 Luca Barbato [EMAIL PROTECTED] wrote: It doesn't *have* to be a perfect succession. It's entirely possible that there will be, say, two divergent EAPI branches or even that there will be a completely unrelated new EAPI format. What's the point in having such thing? The most likely case: if it's decided to have a substantially different new EAPI and incompatible for adding lots of shiny new things like multiABI, whilst keeping the existing EAPI series and extending it for people who don't have time to convert their packages to the new format. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Steve Long wrote: Ciaran McCreesh wrote: Really. It's a heck of a lot cleaner in the filename suffix. Nah, it's an awful hack and you know it. It has nothing to do with package naming and is unnecessary exposure of internal data. Forgive me if I missed this in the previous 500 emails, but I still don't quite understand why you can't just put EAPI=whatever in the ebuild in a fixed place and leave it at that. The biggest objection to this that I've seen is that somebody might want to set it dynamically, which would be impossible to handle without sourcing it. However, you can't possibly put dynamic content in the filename (PLEASE let's not try!), so it sounds like we're stuck with fixed EAPI settings either way. So, why not just put it in the ebuild? If I were designing a binary file format I'd probably have a header with a version number in a fixed position, and a length-of-header field in a fixed position - then you could extend it all you want and old readers could either safely ignore it or at least know where the fields it understands are. Now, obviously we don't want to make every dev do anything like that on a manually-edited file. However, we could simply specify a simple format for the EAPI variable, and then have QA software (repoman/etc) make sure that it is in the correct format. Then it could be safely parsed with a regexp or whatever. Am I missing something? smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 18:59:47 -0500 Richard Freeman [EMAIL PROTECTED] wrote: Am I missing something? Yes. You're missing all the explanations that have already been given about why it's impossible to parse ebuilds using anything other than bash. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: Are you really telling me you are going to write _one_ ebuild with /that/ god-awful hackery in it? Are you really suggesting that no-one ever will? They won't if the spec and the docs say it's restricted to a single instance, which can be checked trivially by repoman. The example given was contrived and not at all representative imo; for instance one could as easily do the same kind of thing with DESCRIPTION, but it would be of little use and just add confusion to no purpose. Except people *do* have generated DESCRIPTION etc, and with good reason. A simple example is the vim-spell-* packages. OK. Do you think a generated EAPI is a good idea? I'm curious as to how that would be reflected in the filename (as well as your reasons ofc.) The pre/post source issue exists regardless of how EAPI is set -- it's just that with filename EAPIs, you aren't restricted to post source changes. And what benefit does that provide, besides making it easier for your package manager? It's not a question of ease. It's a question of being possible. You need to understand the metadata generation process to understand why the package manger has to assume a particular EAPI when generating the metadata. Without the EAPI in the suffix, the assumed EAPI has to be some weird combination of all existing and all possible future EAPIs -- which isn't logically sound. No: without knowing the EAPI when generating said data. If that needs to be known relatively soon in order to generate the rest, extract it early. You still only need to load the file from disk once, and you don't need to source to get that data, given one simple restriction (only declaring it once.) (I note this is a technical consideration of the implementation, given as a reason to change a clean API-- with consequences for workflow.) No no. It's already an ebuild-visible issue, and there's no way it can't be that doesn't involve imposing restrictions upon every single possible future EAPI. The *reason* for the change is about the implementation, and it is not necessary. I accept it would make metadata generation quicker, but the end-user can already use -metadata-transfer atm and never need to run that process. It would save many more cycles if more users did imo (optimising early here seems silly tbh, given that paludis now requires ruby.) Given that, as a user I see no benefit to my machines that would justify the maintenance headache which I know as a coder this will result in. Quite apart from all the changes to supporting tools and workflow, it's pushing an implementation-specific datum into a namespace where it's neither needed nor useful, apart from to the implementation. Someone working on an ebuild will be looking at its text, and an end-user doesn't care. Revision numbers are of note to all parties, by contrast. Ebuilds are not config files. Indeed not, but they can be parsed as such for simple, core, metadata. There is currently no information available from an ebuild that can be parsed by any tool other than bash. OK, but restricting EAPI= across the board (in the way that others have already asked for) and enforcing it via repoman would mean EAPI could easily be extracted. Really. It's a heck of a lot cleaner in the filename suffix. Nah, it's an awful hack and you know it. It has nothing to do with package naming and is unnecessary exposure of internal data. -rN is ok, and there are rules on when and when not to bump rev; this is not. It's much cleaner specified as part of the ebuild in the same way as DESCRIPTION, so long as it is only specified once. Or do you see some real benefit to specifying EAPI more than once as in the example? If so, please share it. And again, you show that you don't understand what's going on. EAPI is only specified once except where developers screw up. The GLEP merely moves the EAPI to being set *before* the metadata is generated, which removes all the restrictions that having EAPI as part of the ebuild's content imposes. Hmm I think you should consider the example that this sub-thread is about, and whether an apology would be in order. Since only declaring it the once /seems/ ok with you, what on Earth is so hard about extracting it? I'm sure ruby has sufficient text processing capability if the C++ is a bit much for you; I remember there was that long-term bug in paludis not being able to deal with whitespace in config files, so clearly something's up with your text-processing. Hope that's finally fixed now. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 23:20 Mon 17 Dec , Piotr Jaroszyński wrote: Abstract This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). Motivation == Including EAPI in the ebuild file extension has the following advantages: * Possibility to extend the versioning rules in an EAPI, and to use them immediately in the Gentoo tree. For example, addition of the scm suffix - GLEP54 [#GLEP54]_. * Possibility to extend the behaviour of inherit and add new global scope functions (as a result of not sourcing ebuilds with unsupported EAPI). Here's some other ideas for how to express EAPI. What if we: Used EAPI-named subdirectories instead of tagging it into the filename? Used (and required) filesystem extended attributes? Stuck ranges into metadata.xml for which EAPIs applied? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Wed, 19 Dec 2007 18:59:47 -0500 Richard Freeman [EMAIL PROTECTED] wrote: Am I missing something? Yes. You're missing all the explanations that have already been given about why it's impossible to parse ebuilds using anything other than bash. If the EAPI can be parsed from a filename without using bash, why couldn't it be parsed from a line in the ebuild contents without using bash? An inelegant solution (but possibly more elegant than using filenames) might be to put the EAPI on the first line of the ebuild, with nothing else on that line. Then a simple head -n 1 file retrieves the EAPI. Certainly not pretty - but perhaps nicer than putting the EAPI in the filename itself. And I don't see how it is any less flexible than putting it in the filename - if nothing else it would allow you a larger character set without making command-line work painful. However, I still don't see how a regexp wouldn't work - if you made the policy that all ebuilds must have a line that says: EAPI=something - exactly. No spaces, quotes mandatory, etc. That can't be any less painful on devs than putting the EAPI in the filename, and it could be checked for by repoman/etc. Or, if package managers are willing to do a little more work we could allow a little whitespace and make things easier on devs. Issues with not using bash to parse the EAPI value would come into play mainly in situations where putting the EAPI in the filename wouldn't work either. smime.p7s Description: S/MIME Cryptographic Signature
EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: On 23:20 Mon 17 Dec , Piotr Jaroszyński wrote: Abstract This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). Motivation == Including EAPI in the ebuild file extension has the following advantages: * Possibility to extend the versioning rules in an EAPI, and to use them immediately in the Gentoo tree. For example, addition of the scm suffix - GLEP54 [#GLEP54]_. * Possibility to extend the behaviour of inherit and add new global scope functions (as a result of not sourcing ebuilds with unsupported EAPI). Here's some other ideas for how to express EAPI. What if we: Used EAPI-named subdirectories instead of tagging it into the filename? Used (and required) filesystem extended attributes? Stuck ranges into metadata.xml for which EAPIs applied? Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. Then we could think about this implementation detail if the best implementation for it is really sticking tags somewhere in the ebuild. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 00:07:35 + Steve Long [EMAIL PROTECTED] wrote: Except people *do* have generated DESCRIPTION etc, and with good reason. A simple example is the vim-spell-* packages. OK. Do you think a generated EAPI is a good idea? I'm curious as to how that would be reflected in the filename (as well as your reasons ofc.) I'm suggesting that if EAPI is a variable, there are use cases for being able to set the variable in ways other than right at the top of the ebuild. If it isn't a variable then those use cases aren't relevant. No: without knowing the EAPI when generating said data. If that needs to be known relatively soon in order to generate the rest, extract it early. You still only need to load the file from disk once, and you don't need to source to get that data, given one simple restriction (only declaring it once.) You can't get the EAPI from the ebuild without knowing what EAPI the ebuild uses. That's one of the points you're missing. (I note this is a technical consideration of the implementation, given as a reason to change a clean API-- with consequences for workflow.) No no. It's already an ebuild-visible issue, and there's no way it can't be that doesn't involve imposing restrictions upon every single possible future EAPI. The *reason* for the change is about the implementation, and it is not necessary. It's an ebuild issue, not a package manager issue. I accept it would make metadata generation quicker, but the end-user can already use -metadata-transfer atm and never need to run that process. It would save many more cycles if more users did imo You're confusing the two different types of metadata. Which again shows that you need to start understanding the metadata process before trying to discuss design decisions relating to it... (optimising early here seems silly tbh, given that paludis now requires ruby.) Eh? Now what're you on about? Given that, as a user I see no benefit to my machines that would justify the maintenance headache which I know as a coder this will result in. There is no maintenance headache. Quite apart from all the changes to supporting tools and workflow, it's pushing an implementation-specific datum into a namespace where it's neither needed nor useful, apart from to the implementation. It's an ebuild issue, not a package manager issue. Ebuilds are not config files. Indeed not, but they can be parsed as such for simple, core, metadata. There is currently no information available from an ebuild that can be parsed by any tool other than bash. OK, but restricting EAPI= across the board (in the way that others have already asked for) and enforcing it via repoman would mean EAPI could easily be extracted. Except that it's an arbitrary, pointless restriction. And again, you show that you don't understand what's going on. EAPI is only specified once except where developers screw up. The GLEP merely moves the EAPI to being set *before* the metadata is generated, which removes all the restrictions that having EAPI as part of the ebuild's content imposes. Hmm I think you should consider the example that this sub-thread is about, and whether an apology would be in order. Huh? Since only declaring it the once /seems/ ok with you, what on Earth is so hard about extracting it? With the current situation, the EAPI has to be known for the EAPI to be calculated. Adding in a pre-pass layer enforcing new file format restrictions does not solve the problem we're trying to address. I'm sure ruby has sufficient text processing capability if the C++ is a bit much for you; I remember there was that long-term bug in paludis not being able to deal with whitespace in config files, so clearly something's up with your text-processing. Hope that's finally fixed now. Again, huh? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 20:28:55 -0500 Richard Freeman [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Wed, 19 Dec 2007 18:59:47 -0500 Richard Freeman [EMAIL PROTECTED] wrote: Am I missing something? Yes. You're missing all the explanations that have already been given about why it's impossible to parse ebuilds using anything other than bash. If the EAPI can be parsed from a filename without using bash, why couldn't it be parsed from a line in the ebuild contents without using bash? Because a) a future EAPI might want to change EAPI into a function rather than a variable, b) there are a zillion ways of setting a variable in bash and people already use all of them and c) introducing new weird format requirements is silly. An inelegant solution (but possibly more elegant than using filenames) might be to put the EAPI on the first line of the ebuild, with nothing else on that line. Then a simple head -n 1 file retrieves the EAPI. Certainly not pretty - but perhaps nicer than putting the EAPI in the filename itself. And I don't see how it is any less flexible than putting it in the filename It imposes format restrictions upon the ebuild. Currently there aren't any such format restrictions. EAPIs are designed to *remove* this kind of inflexibility, not add to it. if nothing else it would allow you a larger character set without making command-line work painful. A large character set for EAPI is silly. Anyone naming an EAPI that isn't a-zA-Z0-9-+_ should be taken out and shot. However, I still don't see how a regexp wouldn't work - if you made the policy that all ebuilds must have a line that says: EAPI=something - exactly. No spaces, quotes mandatory, etc. That can't be any less painful on devs than putting the EAPI in the filename, and it could be checked for by repoman/etc. Or, if package managers are willing to do a little more work we could allow a little whitespace and make things easier on devs. And then EAPI 3 comes along and says Set EAPI using the eapi function. Oops, we're back to the original issue all over again. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 03:31 Thu 20 Dec , Luca Barbato wrote: Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. Then we could think about this implementation detail if the best implementation for it is really sticking tags somewhere in the ebuild. I dug through some old mailing-list archives and found some threads from gentoo-dev in July-August 2005 about EBUILD_FORMAT: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02668.html And here's the post where vapier coined the term EAPI: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02692.html It moved over to gentoo-portage-dev later on: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00203.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00207.html Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 03:31:14 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. An EAPI is a named set of rules telling a package manager how to deal with a particular ebuild and related files, and telling ebuilds upon what they may or may not rely from the package manager. It defines aspects of package manager / ebuild relation including metadata, environment and additional behavioural restrictions. EAPI names are not orderable and have no meaning to the package manager other than their literal value. EAPIs may be entirely incompatible with each other, or they may be mere extensions of a different EAPI, or they may be a subset of a different EAPI, or any combination thereof. A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the cat/pkg-ver as a whole, and is static across that cat/pkg-ver. EAPI is part of a cat/pkg-ver's metadata. All existing EAPIs require that EAPI follows the environment invariancy rules. If a package manager does not support a particular EAPI, the *only* thing it may assume is that it does not support that particular EAPI. It may not assume that it knows what any aspect of that cat/pkg-ver's metadata is, nor may it assume that it knows what cat, pkg or ver are. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/19, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2007 08:12:24 +0100 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: You're done as long as ebuilds are written in bash. Not even that. What if people decide that rather than writing EAPI=blah, eapi blah is cleaner? Yeah, and file names suffixes won't work anymore as soon as it has arbitrarily been decided that prefixes should be used instead, or that EAPI must disappear because using explicit sets of named features is better than using names of some particular sets. That rules only holds as long as they don't change is not an argument, but a truism. What if metadata is moved out of the ebuild, as some people started doing years ago? Which metadata's, the ones from the file contents or the ones from the file name? Seriously, i still don't see the start of a rational argument in your objections to an in-contents alternative. Which lets the subjective disagreement (you prefering to keep bash syntax unrestricted at the price of encumbered files names, and me prefering to restrict it on one particular line for keeping clean name-version.fixed-extension files names), for which argumentation is hopeless too. -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 06:46:44 +0100 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: On 2007/12/19, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2007 08:12:24 +0100 Thomas de Grenier de Latour [EMAIL PROTECTED] wrote: You're done as long as ebuilds are written in bash. Not even that. What if people decide that rather than writing EAPI=blah, eapi blah is cleaner? Yeah, and file names suffixes won't work anymore as soon as it has arbitrarily been decided that prefixes should be used instead, or that EAPI must disappear because using explicit sets of named features is better than using names of some particular sets. That rules only holds as long as they don't change is not an argument, but a truism. Uh, it works in both those cases. The package manager will simply not see the ebuild at all. Which is pretty much the point... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in rox-base/rox: ChangeLog rox-2.7-r2.ebuild
On 15:05 Mon 17 Dec , Jim Ramsay (lack) wrote:
lack07/12/17 15:05:57
Modified: ChangeLog
Added:rox-2.7-r2.ebuild
Log:
Started using EAPI=1 and IUSE defaults. Also added new 'video' flag to
IUSE (bug 202333)
(Portage version: 2.1.3.19)
1.1 rox-base/rox/rox-2.7-r2.ebuild
file :
http://sources.gentoo.org/viewcvs.py/gentoo-x86/rox-base/rox/rox-2.7-r2.ebuild?rev=1.1view=markup
plain:
http://sources.gentoo.org/viewcvs.py/gentoo-x86/rox-base/rox/rox-2.7-r2.ebuild?rev=1.1content-type=text/plain
IUSE=+svg +video
svg already defaults on for all the desktop profiles, so I'm not really
sure what that's gaining you.
RDEPEND==x11-libs/gtk+-2.4
=dev-libs/glib-2.2
=dev-libs/libxml2-2.4.23
=x11-misc/shared-mime-info-0.14
svg? ( gnome-base/librsvg )
!ppc? ( rox-base/mime-editor
rox-base/thumbs
video? ( rox-extra/videothumbnail ) )
PPC users aren't supposed to get this stuff? If not, is it even a real
dependency?
src_compile() {
cd ${APPNAME}
# Most rox self-compiles have a 'read' call to wait for the user to
# press return if the compile fails.
# Find and remove this:
sed -i.bak -e 's/\read WAIT\/#read/' AppRun
./AppRun --compile || die make failed
(cd src; make clean) /dev/null
# don't need these directories anymore
if [ -n ${KEEP_SRC} ]; then
(cd src; make clean) /dev/null
Subshells are icky.
else
rm -rf src
fi
rm -fr build
# Restore the original AppRun
mv AppRun.bak AppRun
}
# new streamlined install
src_install() {
doman rox.1
dodir ${APPDIR}
cp -r ${APPNAME}/ ${D}/${APPDIR}
# add documentation to be proper
( cd ${APPNAME}/Help
dodoc Changes README README-es TODO
)
Icky.
chmod 0755 ${D}/usr/bin/${WRAPPERNAME}
chmod 0755 ${D}/usr/bin/${WRAPPERNAME}uri
fperms?
make_desktop_entry ${WRAPPERNAME} ${APPNAME} ${APPNAME}.png
System;Utility;Core;ROX
Thought I saw something about desktop entries dropping the suffix for
the icon, but I don't recall the details.
Thanks,
Donnie
--
[EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: On 03:31 Thu 20 Dec , Luca Barbato wrote: Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. Then we could think about this implementation detail if the best implementation for it is really sticking tags somewhere in the ebuild. I dug through some old mailing-list archives and found some threads from gentoo-dev in July-August 2005 about EBUILD_FORMAT: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02668.html And here's the post where vapier coined the term EAPI: http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg02692.html It moved over to gentoo-portage-dev later on: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00203.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg00207.html Sigh, ok, but that isn't a long thread or an handful of threads scattered across mailing lists. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Thu, 20 Dec 2007 03:31:14 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. An EAPI is a named set of rules telling a package manager how to deal with a particular ebuild and related files, and telling ebuilds upon what they may or may not rely from the package manager. It defines aspects of package manager / ebuild relation including metadata, environment and additional behavioural restrictions. EAPI names are not orderable and have no meaning to the package manager other than their literal value. EAPIs may be entirely incompatible with each other, or they may be mere extensions of a different EAPI, or they may be a subset of a different EAPI, or any combination thereof. A cat/pkg-ver has exactly one EAPI. That EAPI belongs to the cat/pkg-ver as a whole, and is static across that cat/pkg-ver. EAPI is part of a cat/pkg-ver's metadata. All existing EAPIs require that EAPI follows the environment invariancy rules. If a package manager does not support a particular EAPI, the *only* thing it may assume is that it does not support that particular EAPI. It may not assume that it knows what any aspect of that cat/pkg-ver's metadata is, nor may it assume that it knows what cat, pkg or ver are. Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? About the problem it is trying to solve, I think it basically boils down to make sure the package manager: - ignores ebuilds with syntax different from the one it can handle - can be safely updated even in the situation the tree has ebuilds it cannot parse. eapi, as defined above, does address those point in the best way? those point are what we are trying to address with eapi? -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
