[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 27 Dec 2007 18:11:33 +: On Thu, 27 Dec 2007 18:03:27 + Roy Marples [EMAIL PROTECTED] wrote: On Thu, 2007-12-27 at 17:43 +, Ciaran McCreesh wrote: Or to put it another way, you're objecting to painting the house pink rather than green because you don't like pink (because your last house was green too), ignoring that it's been demonstrated that when painted green, it's impossible to add a conservatory and central heating because the green paint will catch fire and kill everyone. Using your analogy you should then recognise that there is a strong dislike for pink and should seek a new colour that allows the building of said extensions. And what colour would that be? We've already ruled out purple, brown and yellow, and no-one has yet found any other colour of paint. OK, I still think putting it in the file name is less prone to error, but what about this, call it blue if you will? 1) Strictly define and restrict EAPI to a specific form in a specific file location (say EAPI=value, unquoted, as the first line of the file). 2) Quickly define say EAPI=1_ext, that further defines say SUB_EAPI, or EBPI, or EAPI-B, which is allowed to be a function or whatever, with the only further restrictions on it being those that would apply to EAPI- suffix file names. That should give us the nailed down qualities of putting it in the file name, while providing the flexibility therein as well. There may be a bit of delay while we wait for non-EAPI aware PMs to drop out, but by the sounds of things, it's not going to be much more than fighting this thru and getting it approved is likely to be (a couple months, anyway), and as it's a different EAPI, EAPI aware PMs should ignore it if they don't understand it. PMs can then do a pre-parse, looking at the first line in specified format just as they'd otherwise look at the filename. With that information in hand, if the EAPI is 1_ext and they understand that, they'll immediately know to check SUB_EAPI or whatever, which is as flexible as bash parsing is. If at some point in the future we want to go to XML based formats or whatever, we cross that bridge when we come to it and /then/ we do the filename thing, if it's still thought to be necessary. Meanwhile, other (master) EAPIs may yet be defined, if their practical use is restricted enough to fit within the strict first line EAPI=whatever rule above, and those could include further refinements on the SUB_EAPI theme if they become necessary, WITHOUT a multiplication if ebuild-xxx extensions. The big drawback I see here is the the forced delay until EAPI aware PMs can be assumed, but as I said, it seems that's going to be the case with the current proposal anyway, simply because of the amount of resistance to it and the delay in approval that's likely to mean, even if it /is/ ultimately approved. -- 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: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote:
c) It's an extremely bizarre restriction, the likes of which do not
currently exist, that will confuse the hell out of all the people
that don't realise that such a restriction exists.
I don't think it's that hard to understand You can only set EAPI *once* in
your ebuild. Are you really saying devs won't get that?
Who are these mythical people? Devs take a quiz: the EAPI setting
restrictions can easily be added to it, as well as being documented
elsewhere.
That would of course have to be done doubly so for your GLEP, which imposes
a much more bizarre restriction: that the EAPI must go in the filename.
Devs are already used to follow numerous conventions in the way they
format their ebuilds.
And they already arbitrarily don't follow them. We get people screwing
up whitespace and brackets in dep strings, for example (Portage doesn't
error check these very well).
Odd: I found repoman very fussy about those. Leaving the digs at portage
aside, that's what the new commit reviews are about.
d) It introduces a new prepass parse layer to an already complex
process.
Both solutions add some new steps to this process, and it doesn't look
to me like there's a significant difference beetween their respective
added complexity. That said, you're the PM dev here, not me, so if
you confirm that implementation of an in-contents solution is
significantly harder, then i will accept the argument.
It's not harder (assuming the syntax is well defined -- single, double
or no quotes? export? leading whitespace? is it the first or the last
match of EAPI= that's taken?). It's just messy, because we'd have to
deal with stupid cases like:
DESCRPTION=Config file to make Paludis support
EAPI='4' packages
Wow, yet another contrived b0rkage. You really don't have a very high
opinion of Gentoo devs, do you?
EAPI=1
export EAPI=2
src_compile() {
cat END somefile
EAPI=3
END
}
All those would be dealt with by the well-defined syntax. I'd start with:
EAPI=foo on its own on a line. The first setting is taken.
e) The Portage guys said no to it.
When/where? I've only seen Marius commenting here, but not on that
aspect. Also, i've read this 2005 EBUILD_FORMAT discussion that
Steve Long has pointed [1], where Brian was against non-Bash parsing,
but:
- he was against changing files extension too,
- the flaws in the EAPI system designed at this time is what led to
rethinking it now.
If i've missed something since then (and that's likely), could you
give me a pointer to the archives? Thanks.
A while after that Brian and I had a huge lengthy argument on IRC about
it. I don't have IRC logs that far back, which is kind of a shame
because we covered pretty much all of the things that people are
moaning about now...
Somehow I'm not reading Brian and I agreed that.. and it concerns me that
we haven't so far had portage and pkgcore devs chiming in that your GLEP is
just what they want as the solution to several issues, meriting the work
required to change over, and the future hackiness and restrictions it
imposes.
My point here is that the in-contents alternative is just a syntaxic
rule which defines a first-pass extraction of a value from an ebuild
file (as opposed to an ebuild file name extension). How it is then
used (what the eapi function does, if anything, or whether this
value is the definitive EAPI, or how EAPI vs. eclasses is handled,
etc.) can be subject to future changes depending on this value. That's
part of why this solution is not more restrictive than the file name
extension approach.
But then you get the highly weird result of setting, say, EAPI=4 in
the ebuild but the c/p-v actually having EAPI=3 because of weird hard
to see behind the scenes eclass voodoo.
That sounds like a borked package manager, and something which should not be
allowed per the spec. If an ebuild author sets EAPI that's what the
metadata EAPI must reflect.
That's equivalent to the using
the wrong file extension and then overriding with a variable
situation, except that you're effectively requiring it for future
changes rather than making it something that's a big flashy warning.
Or you're just contriving examples.
(From a technical perspective, changing EAPI mid-source is a massive
pain in the ass. EAPI pretty much has to be able to tinker with PATH
and friends, and there's no sane way of modifying variables as soon as
another variable changes.
It's up to the eclass/ebuild author to deal with the consequences of code
they write. In the same light, it's up to the PM devs to ensure that the
EAPIs they support work correctly.
For example, and not saying that this
specific case is desirable, EAPI foo could require that the first 'sed'
in PATH be GNU sed, whilst EAPI bar could require that it be the normal
system sed.)
If you could come up with a more cogent example (that actually poses a
technical challenge) perhaps your peers
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sun, 23 Dec 2007 21:01:15 +: I don't accept that I took it to that level, but I apologise unreservedly for responding to it. Thanks. Now to leave it behind. -- 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: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 14:29:25 +0100 The majority of devs don't want to know how portage or paludis work internally, that's not what interests most of us. Which is fine. But then, the majority of devs shouldn't expect to be able to provide opinions when it comes to the more technical aspects. Yes, but they can smell a nasty hack when they see one; starting with the fact that the API is no longer as clean. On a somewhat related note : I noticed that among the massive thread, you have brought up several times the issue of cache generation, saying that it was a complicated process. Maybe this process needs to be reworked before the whole EAPI issue can be resolved? That's partly what the GLEP is doing. Making it any simpler, unfortunately, would involve either a huuge performance hit (we're talking two orders of magnitude here) or removing metadata from the ebuilds entirely -- neither of which are viable solutions. Oh, I thought this wasn't about performance? Nor indeed about cache generation. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 24 Dec 2007 11:19:18 + Steve Long [EMAIL PROTECTED] wrote: Which is fine. But then, the majority of devs shouldn't expect to be able to provide opinions when it comes to the more technical aspects. Yes, but they can smell a nasty hack when they see one; starting with the fact that the API is no longer as clean. Clearly not... On a somewhat related note : I noticed that among the massive thread, you have brought up several times the issue of cache generation, saying that it was a complicated process. Maybe this process needs to be reworked before the whole EAPI issue can be resolved? That's partly what the GLEP is doing. Making it any simpler, unfortunately, would involve either a huuge performance hit (we're talking two orders of magnitude here) or removing metadata from the ebuilds entirely -- neither of which are viable solutions. Oh, I thought this wasn't about performance? Nor indeed about cache generation. The GLEP is not about performance, but any solution that forces the introduction of a slowdown of more than, say, 20%, isn't viable. In particular, making a typical emerge -pv world take of the order of 0.1s per c/p-v's metadata that's needed (as a very rough idea, we're talking a thousand upwards of these on a typical system) isn't even remotely feasible. And no, the GLEP doesn't directly address cache generation. But equally, it can't ignore it simply because without some form of static metadata cache package managers can't be implemented in a way acceptable to end users. You see, there's this thing called the big picture... -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Duncan wrote: Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 06:35:07 +: Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do what he says. [1] http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh- uncensored I read the same interview and didn't take it like that, but regardless, why are you dropping this discussion to a new low? Until you came along, altho there was disagreement, people were at least maintaining some civility in the discussion. Then you come along, and I see multiple personal attack posts. That's not right, and until now, we'd avoided it. Please apologize. Just because you don't agree with someone doesn't mean you have to take it to the level you just have, and it does NOT help. (I thank you for your agreement with me, as it happens, disagreeing with Ciaran, on the users thing, but again, we had kept it civil. Here, you aren't, and it doesn't belong on the list, and regardless of whether you just agreed with me or not, you need called on it, and I don't see any other posts doing it yet, so...) I don't accept that I took it to that level, but I apologise unreservedly for responding to it. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Piotr Jaroszy?ski wrote: Hello, I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. Based on your summary of the suggestions on the list, I believe you misunderstood what many of us were arguing for. * Set the EAPI inside the ebuild in a way that makes it easy to fetch it This is ok as atm only EAPI=1 is in the tree, so there is no backward compatibility issue. AND * Have a new ebuild/eclass extension .eapi-$EAPI This is for ebuilds for other package managers; it is envisaged by some that this will become the new ebuild format since it enables quick access to the EAPI without accessing the file contents. Full ebuild names are the primary key for the portage database. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 24 Dec 2007 06:03:12 + Steve Long [EMAIL PROTECTED] wrote: * Set the EAPI inside the ebuild in a way that makes it easy to fetch it This is ok as atm only EAPI=1 is in the tree, so there is no backward compatibility issue. It's both a backwards and a forwards compatibility issue. * Have a new ebuild/eclass extension .eapi-$EAPI This is for ebuilds for other package managers; it is envisaged by some that this will become the new ebuild format since it enables quick access to the EAPI without accessing the file contents. Full ebuild names are the primary key for the portage database. Full ebuild names as a primary key is bad. It means you have to normalise versions early on -- equality and equivalence are different for ebuild names already. And eclasses are an entirely separate issue. They need to be dealt with differently, ideally starting with EAPI 2. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 07:12:28 +: Funny thing is I think the USE-flag metadata thing would have breezed through as a GLEP; I don't recall one person saying they thought it was a bad idea. But you do recall people saying how it needed extending to be useful. Yes, it would have breezed through as a GLEP, but it would have had a half dozen small additions that would have made it a lot more useful. ++, as I think pretty much everybody agrees at this point. -- 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: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Steve Long [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 06:35:07 +: Oh yeah I forgot, McCreesh thinks they're all idiots[1], so let's just do what he says. [1] http://lab.obsethryl.eu/content/paludis-gentoo-and-ciaran-mccreesh- uncensored I read the same interview and didn't take it like that, but regardless, why are you dropping this discussion to a new low? Until you came along, altho there was disagreement, people were at least maintaining some civility in the discussion. Then you come along, and I see multiple personal attack posts. That's not right, and until now, we'd avoided it. Please apologize. Just because you don't agree with someone doesn't mean you have to take it to the level you just have, and it does NOT help. (I thank you for your agreement with me, as it happens, disagreeing with Ciaran, on the users thing, but again, we had kept it civil. Here, you aren't, and it doesn't belong on the list, and regardless of whether you just agreed with me or not, you need called on it, and I don't see any other posts doing it yet, so...) -- 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: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 07:13:28 +: On Sat, 22 Dec 2007 04:19:45 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Piotr Jaroszyński wrote: On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: So please make those people understand, so they can comment usefully. Are we in the elementary school or something? This is really getting ridiculous. ietf.org Are they ridiculous? Do you see them explaining what TCP is in great detail in every single publication that mentions TCP? No, but ietf.org /does/ document what TCP is, and /not/ just in code either, so it's there for folks that need it. I actually thought the point was pretty effective, given what it was in reply to. If it were me the elementary school reply was made to, I'd have felt it within my rights to ask for an apology. I therefore considered the ietf remark a rather clever reply to the innuendo, making the point delicately, while avoiding the loss of face challenge asking for an apology presents. -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Saturday 22 of December 2007 12:03:33 Duncan wrote: I actually thought the point was pretty effective, given what it was in reply to. If it were me the elementary school reply was made to, I'd have felt it within my rights to ask for an apology. I therefore considered the ietf remark a rather clever reply to the innuendo, making the point delicately, while avoiding the loss of face challenge asking for an apology presents. How is it fair that some people do their own research and some ask to be educated and for the discussion to be delayed? -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 15:50:43 +0100: On Saturday 22 of December 2007 12:03:33 Duncan wrote: If it were me the elementary school reply was made to, I'd have felt it within my rights to ask for an apology. I therefore considered the ietf remark a rather clever reply to the innuendo, making the point delicately, while avoiding the loss of face challenge asking for an apology presents. How is it fair that some people do their own research and some ask to be educated and for the discussion to be delayed? I wasn't arguing that such was fair. The world isn't fair. I /was/ arguing that (IMO) the elementary school comment was out of line, and that had it been made to me, I'd have considered asking for an apology. Instead, simply (re)stating that it's not something that can be easily explained and that it was your viewpoint that documentation wasn't needed (yes, I /know/ it's a restatement, there's no harm in showing a bit of exasperation in having to repeat it by mentioning the repeat), as Ciaran has been so patiently doing (thanks, Ciaran), would have (IMO) been more appropriate. -- 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: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Piotr Jaroszyński [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 16:43:10 +0100: Abstract This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). This one does seem a marked improvement. Thanks. It really is noticeably better. =8^) Specification = I made this suggestion earlier but it was deep in a subthread and perhaps missed. Else, maybe it didn't reach you in time for this update. Anyway, here it is again: Right at this point, between the Specification header and the existing Let's call... below, for clarity I believe we need a formal syntax note, probably similar in format to the the one found in many manpages, where it is called Synopsis. Checking other GLEPs, I don't see anything like this in most, but I do believe it /would/ help clarify and is thus worth it. Like the following (I'm omitting the RST stuff): Syntax: PF.ebuild[-EAPI] Where: PF is the full package name, version, and revision, as in man 5 ebuild. -EAPI is optional. EAPI is the named EAPI. Explanation: Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps: It may also be worthwhile to specifically note /somewhere/ that this only specifies *.ebuild* format, thus leaving other forms (say xbuild) for further changes, if it should ever be decided necessary. Combined, these two changes would have significantly reduced my initial confusion upon reading the GLEP, thus leading to a false impression and raising objections to the idea that didn't apply, once I understood more clearly what, specifically, was being proposed. -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Saturday 22 of December 2007 19:26:08 Duncan wrote: I made this suggestion earlier but it was deep in a subthread and perhaps missed. Else, maybe it didn't reach you in time for this update. Anyway, here it is again: (snip) Syntax: PF.ebuild[-EAPI] Thanks, added syntax specification for the ebuild filename extension. It may also be worthwhile to specifically note /somewhere/ that this only specifies *.ebuild* format, thus leaving other forms (say xbuild) for further changes, if it should ever be decided necessary. I think it will be the job of the xbuild GLEP to specify what from the ebuild format applies and what does not. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Bo Ørsted Andresen wrote: On Friday 21 December 2007 03:41:04 Luca Barbato wrote: * We have to wait a year before we can use it. We have to wait till we got a new release and I hope it isn't 12months. And then we have to wait till noone use a version of portage that sources the ebuild to get the EAPI. Unless we change the file name.. We generally make sure that the tree is compatible with portage versions released in the past six months, so if you don't have version released in that timeframe it is possible that you won't be able to use the tree anymore.[1] What applications are so important that require this change in order to work, that we have to go through the tool modifications now rather than wait a few months and let the newer versions of portage deal with it, without us having to make any changes at all? After all we can use EAPI=1 already, and if the portage team want to put more features in, they're at liberty to define EAPI=2 or any other. It appears this is being rushed through: we can have some undefined new features (well Paludis users can) now, if only we allow unbounded changes to the filename suffix. That's not a good enough reason. [1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Fri, 21 Dec 2007 13:59:22 +: On Fri, 21 Dec 2007 08:43:43 -0500 Richard Freeman [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Please don't comment any further until you understand how this whole thing works. I think this is a bit of an unrealistic expectation. This change impacts EVERYBODY - devs, users, etc. What. It's a small change that's only visible to developers and power users. But it affects all developers (and power users) in the routine way they do their job, dealing with ebuilds (or ebuilds plus whatever, if this GLEP goes thru). As such, it's a big change, because it affects how a lot of people do their routine work. Yes, that's quibbling over semantics and viewpoint, but it's obvious /some/ people consider it a big change, big enough for them to make a big deal about, anyway, which is what matters in terms of discussion and ultimate acception/rejection of the GLEP. Makes a low-level detail more visible to users. Users don't see .ebuild files. Gentoo users, as often used in the context of this list (from my observation), do. Gentoo users are, as used here, Gentoo system sysadmins by another name. As such, they've always been expected to be at what the general IT world would consider at minimum power user, certainly not the luser that's the general IT world's usage of user. By definition, Gentoo users are expected to be able to RTFM, and expected to actually /enjoy/ the extra control of being able to mess with ebuild files and the like. Otherwise, why are they using Gentoo at all, when it's targeted at that power user, and there are other distributions out there directly targeted at the (l)user level? So, users, as used on this list, *do* see ebuild files, or at minimum, cannot be reasonably said *not* to see them, since many of them in fact do see them and make use of them, in overlays and the like. As for the generally IT world usage of the term, (l)user, that doesn't come up so often here, because it's not what we deal with. Dealing with them would be the job of /our/ users -- Gentoo sysadmins by another name. You can't make a wild change to how EAPIs are specified - since old PMs will expect it to be in the filename in a particular format. You can make entirely arbitrary changes to EAPIs with suffixes, provided only that you don't use either .ebuild or .ebuild-(any-existing-eapi). OK, first, a comment on the GLEP itself: I just looked at it again, and realized it doesn't actually /specify/ the name format in so many words or in commonly accepted syntax form. One can see what's expected based on the /examples/, but it's not specified... anywhere that I could see. So the GLEP needs something like the below (may not be technically correct, but as an example to be corrected as necessary when added to the GLEP) syntax specified: PF.ebuild[-suffix] IMO that's the key to beginning to clear up my (I think former) confusion. Without that clearly stated, I was conflating the two possible changes, the one given by the GLEP, and the one left unspec-ed, and thus reserved for the future and/or other non-Gentoo usage, extensions /other/ than .ebuild[-suffix]. Given the conflation, I was then left confused by the GLEP requirement that the EAPI not be changed from that found in the filename (with the filename EAPI defaulting to 0 if not given), set against the argument that EAPI could then at some point be made dynamic, or otherwise less firmly specified than filename semantics requires. Separating the concepts, then, clears up the confusion, since the possibility is left open to change to something /other/ than .ebuild[-suffix], say fbuild, in the future (or for other than main Gentoo tree) as necessary, and the new (fbuild or whatever) format would be free to break all the current rules associated with .ebuild[-suffix] as deemed necessary. So now I see how you could state they must remain the same (in the glep) yet allow for dynamically setting them (post-source) in future non- ebuild* formats. Further suggestion for the GLEP, then: In addition to specifying syntax explicitly, note explicitly as well, that this glep deals with .ebuild* only, and that one possible mechanism for future incompatible changes would therefore be to change the extension to something other than .ebuild*. This should eliminate an entire class of objections (and simple confusion), including my main previous one, due to the present less than clear specification and the confusion it caused. (/NOW/ I see...! =8^) -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 06:35:07 + Steve Long [EMAIL PROTECTED] wrote: Oh yeah I forgot, McCreesh thinks they're all idiots[1] No no. I think some of them are idiots. Get it right. Funny thing is I think the USE-flag metadata thing would have breezed through as a GLEP; I don't recall one person saying they thought it was a bad idea. But you do recall people saying how it needed extending to be useful. Yes, it would have breezed through as a GLEP, but it would have had a half dozen small additions that would have made it a lot more useful. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 19 Dec 2007 17:50:19 +0100: On Wed, Dec 19, 2007 at 11:03:54AM -0500, Jim Ramsay wrote: 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. Quoting CiaranM from a different subthread, defining EAPI: 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. Now, we already had someone mention using two together, prefix (which seems to have been defined as an EAPI for the purposes of this discussion, I don't deal with it so haven't the foggiest about it, personally) and EAPI-1. If that portion of Ciaran's definition quoted above stands, that usage would be defined as illegal, thus anything using it broken. The work-around as Jim mentions above would be defining a third EAPI combining as a superset the other two. One could then create ebuilds using that third EAPI. Of course, until at least one of the available package managers supports that third EAPI, ebuilds created to use it wouldn't be of much use, and until portage, being the official Gentoo PM, supported it, said ebuilds could not be placed in the Gentoo-x86 tree. The question, then, is whether anyone, particularly those working with PMs other than paludis (Ciaran being the lead on it so presumably his EAPI definition works for it), disagrees with that portion of Ciaran's EAPI definition. I've seen no such direct disagreement so far, with the presumed exception of the person mentioning already combining two (without creating a third out of them) in prefix, of course. -- 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: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 20 Dec 2007 03:54:00 +: 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. So you're proposing putting the function into the filename? As he stated, the only credible reason (so far given) bash must be used to parse EAPI is if it's dynamic, say a function, and that won't work so well in a filename either. Thus, putting EAPI in the filename pretty much eliminates the possibility of it being a function, and we're back to the original question, instead of a GLEP allowing it in the filename, why not a GLEP specifying the format of that single variable in the file contents well enough to parse without bash? Or, if you are proposing that the pre-source EAPI in the filename could be superseded by a function, if that is specifically allowed by the (pre- source) EAPI defined in the filename, then we are back to what I suggested earlier, that you specifically said wasn't necessary (and I basically deferred to your judgement), that the pre-source and post- source EAPI be specifically allowed to be different. Either the EAPI must be static, so it can be set in the filename, or it can be set dynamically, in which case allowing the pre-source and post- source EAPI to be different actually makes sense. That said, I do agree that putting it in the filename seems safer, as if the PM doesn't understand that EAPI, it can stop right at the filename, and doesn't have to worry about parsing the contents of the file itself at all, period. That's safer than having to parse it at least minimally, to find out at least the EAPI, before deciding whether it can go further. Thus, regardless of the function thing, I support EAPI in the filename as simply safer. -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 09:43:59 + (UTC) Duncan [EMAIL PROTECTED] wrote: 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. So you're proposing putting the function into the filename? No, I'm saying that the data goes into the filename. As he stated, the only credible reason (so far given) bash must be used to parse EAPI is if it's dynamic, say a function, and that won't work so well in a filename either. No no no. Bash is the only thing that can parse bash. Ebuilds are bash. Thus, putting EAPI in the filename pretty much eliminates the possibility of it being a function, and we're back to the original question, instead of a GLEP allowing it in the filename, why not a GLEP specifying the format of that single variable in the file contents well enough to parse without bash? Because that would be introducing a new, non-extensible, inflexible requirement upon the content of ebuilds, and the goal of EAPI is to avoid doing exactly that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Thu, 20 Dec 2007 09:43:59 + (UTC) Duncan [EMAIL PROTECTED] wrote: 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. So you're proposing putting the function into the filename? No, I'm saying that the data goes into the filename. then why not let it go into the file content? if data goes into file content, then function is not needed you are contradicting with yourself here. As he stated, the only credible reason (so far given) bash must be used to parse EAPI is if it's dynamic, say a function, and that won't work so well in a filename either. No no no. Bash is the only thing that can parse bash. Ebuilds are bash. Getting the first line of a file using whatever language is just a piece of cake. And I don't see why setting a rule on the syntax of EAPI definition is so silly. How many ways to define a variable in bash can you think of? Is it that hard to come up with a way to normalized the definition? Just like charset code normalization, e.g. from UTF-8 to utf8? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
[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
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] 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] 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] 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
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 17 Dec 2007 23:20:01 +0100: Let's call the EAPI included in the ebuild filename the pre-source EAPI, and the EAPI set inside the ebuild the post-source EAPI. Given these two, the final EAPI used by the ebuild can be established by following these steps: * If the pre-source EAPI is not set it defaults to 0. * If the pre-source EAPI is not recognised it is returned immediately. * If the post-source EAPI is not set, it defaults to the pre-source EAPI. * post-source EAPI is returned. The above process should be only used to generate the metadata cache. Should the pre-source EAPI be unsupported the cache entry cannot be generated. Ebuilds with unsupported EAPIs are masked. QA tools should consider it an error for both EAPIs to be set explicitly to different values. Package managers may warn, but must use the post-source EAPI in such cases. Up until that last quoted paragraph above, I had an entirely different idea of where this was headed. It's either incredibly stupid, or it's great outside-the-box thinking that just might be useful. Might as well ask or I'll never know. =8^) Put directly, what is stopping us from actually allowing DIFFERENT pre- source and post-source EAPI values? Here's the thinking. In the various PM discussions I've seen, it hasn't been unusual to see remarks about (previously) waiting for support in stable, and now about EAPI incompatibility, simply due to /parsing/ the ebuild. This could offer a way around the problem, by separating initial parsing/dependency EAPI and actual build/merge EAPI. The pre-source EAPI could state the EAPI support required to properly /source/parse/ the ebuild and generate the dependency tree, etc, while allowing the post- source EAPI to be different then allows additional flexibility in actual build/merge required EAPI. We'd then have two choices in terms of declaring pre-source support (as opposed to post-source, full merge support). 1) Simply that a compatible pre-source EAPI shouldn't blow up if sourced while calculating dependencies or the like -- the ebuild may be safely sourced and it shouldn't negatively affect the dependency tree for unrelated packages, but dependencies for that specific package may or may not be correct. -OR- 2) That a compatible pre-source EAPI package, when sourced, should allow generation of a reasonably reliable dependency tree for the package in question, presumably including a PM upgrade as part of that dependency tree. If we chose policy one, because unsupported pre-source EAPIs are explicitly NOT to be parsed, it would allow any arbitrary package format change as may eventually be found necessary, including breaking the bash- parsable assumption, if at some point that is found convenient. Conversely, supported pre-source EAPIs could at least be depended upon not to break the PM or dependency resolution for other branches of the dependency tree. As the ebuild was parsed, if a different post-source EAPI were found, a notice would be printed that said package couldn't be merged with the existing package manager, but the other branches of the update/merge would proceed, allowing the incompatibility for that package to be resolved later. If we chose policy two and pre-source and post-source EAPIs differed, part of the dependency tree for that package should include a PM supporting the post-source EAPI, in which case the other (post-source EAPI compatible) branches could be merged, then the required post-EAPI PM (presumably an upgrade, remember, this would ONLY occur if the two EAPIs differed so it wouldn't happen in the general case) would be merged, that specific package dependency tree branch recalculated post PM upgrade, and then that package merged. So the difference between policies for the user would be policy one would generally require a manual PM change intervention, while policy two could at least in theory (absent explicit blockers, etc) be handled entirely automatically. Policy two has stricter requirements for developers, however, and would thus be easier to break. OK, so it's off the wall, but tell me, is it useful and implementable, or just stupid? -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 09:53:50 + (UTC) Duncan [EMAIL PROTECTED] wrote: Put directly, what is stopping us from actually allowing DIFFERENT pre- source and post-source EAPI values? That's effectively what happens when a package manager sources a current EAPI=1 in a variable ebuild. Here's the thinking. In the various PM discussions I've seen, it hasn't been unusual to see remarks about (previously) waiting for support in stable, and now about EAPI incompatibility, simply due to /parsing/ the ebuild. This could offer a way around the problem, by separating initial parsing/dependency EAPI and actual build/merge EAPI. The pre-source EAPI could state the EAPI support required to properly /source/parse/ the ebuild and generate the dependency tree, etc, while allowing the post- source EAPI to be different then allows additional flexibility in actual build/merge required EAPI. We'd then have two choices in terms of declaring pre-source support (as opposed to post-source, full merge support). There's no advantage to doing so. If you don't support the EAPI, the only thing you can do is say that you don't support the EAPI. 1) Simply that a compatible pre-source EAPI shouldn't blow up if sourced while calculating dependencies or the like -- the ebuild may be safely sourced and it shouldn't negatively affect the dependency tree for unrelated packages, but dependencies for that specific package may or may not be correct. But all you get is the knowledge that the ebuild uses an unsupported EAPI. Which you know already. I should state this explicitly: If an ebuild's EAPI isn't recognised by the package manager, the package manager can't and mustn't sort of work with that ebuild; there is no such thing as a sort of supported EAPI. The package manager can either ignore the ebuild entirely or display it in some kind of super fancy masked due to EAPI way -- and if it does the latter, the *only* information the package manager has about the ebuild is that its EAPI is unsupported. The package manager can't guess ooh, well it sets SLOT, so I can assume that SLOT means what I think it does -- a future EAPI might do something crazy like say that if SLOT=dynamic, the speshul pkg_slot function is used. The package manager can't even assume that it knows what the unsupported EAPI's name really is or that it knows what the unsupported package's version is. 2) That a compatible pre-source EAPI package, when sourced, should allow generation of a reasonably reliable dependency tree for the package in question, presumably including a PM upgrade as part of that dependency tree. EAPIs aren't to specify the dependency tree. There's the added problem that it breaks the concept of metadata cache. That gets hairy. OK, so it's off the wall, but tell me, is it useful and implementable, or just stupid? It's implementable. It would just be of no use. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Thomas de Grenier de Latour wrote:
On 2007/12/18, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
I probably missed some of the stuff leading up to this GLEP, but
what is the problem with having the EAPI in the file and
determining it by looking at the file contents?
Motivation, second bullet point:
| Possibility to extend the behaviour of inherit and add new global
| scope functions (as a result of not sourcing ebuilds with
| unsupported EAPI).
Why can't it be in the file but readable without sourcing? For instance,
it could be mandatory that EAPI=X, if present, must be the first
non-blank and non-comment line of the ebuild (and it would then be
checked after sourcing, if the ebuild is sourced, to bug on cases where
it's redefined or unset afterwards).
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.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, Dec 18, 2007 at 05:05:13PM +, Steve Long wrote:
Thomas de Grenier de Latour wrote:
On 2007/12/18, Ciaran McCreesh [EMAIL PROTECTED] wrote:
On Mon, 17 Dec 2007 17:10:46 -0700
Joe Peterson [EMAIL PROTECTED] wrote:
I probably missed some of the stuff leading up to this GLEP, but
what is the problem with having the EAPI in the file and
determining it by looking at the file contents?
Motivation, second bullet point:
| Possibility to extend the behaviour of inherit and add new global
| scope functions (as a result of not sourcing ebuilds with
| unsupported EAPI).
Why can't it be in the file but readable without sourcing? For instance,
it could be mandatory that EAPI=X, if present, must be the first
non-blank and non-comment line of the ebuild (and it would then be
checked after sourcing, if the ebuild is sourced, to bug on cases where
it's redefined or unset afterwards).
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
if [[ -z ${PV/?.?/} ]] ; then
EAPI=bar-1
elif [[ -z ${PV/?.?.?/} ]] ; then
EAPI=0
else
EAPI=1
fi
--- 8 ---
So please, no hacks.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgpuCiBgvg9Lx.pgp
Description: PGP signature
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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? 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)? -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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? - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpJ3tGZSnUfw.pgp Description: PGP signature
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tuesday 18 of December 2007 20:45:44 Duncan wrote: How about when we have a dozen or so EAPIs active, several of which apply to a specific ebuild? Where is this idea of mixing EAPIs coming from? It really doesn't make much sense. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007 21:11:20 +0100: On Tuesday 18 of December 2007 20:45:44 Duncan wrote: How about when we have a dozen or so EAPIs active, several of which apply to a specific ebuild? Where is this idea of mixing EAPIs coming from? It really doesn't make much sense. If EAPI is defined as a particular set of features and rules as grouped together under a specific EAPI label (Ciaran's general definition), and is specifically not ordered, as is the case, thus allowing, potentially, multiple EAPIs to evolve in parallel (Grobian's message), as the upthread argues is possible, even likely... And if a particular ebuild uses features from a non-conflicting super-set of several such EAPIs (Ulrich's message) ... Then said ebuild under this GLEP would need labeled with the lot of 'em. The message to which I replied (Fernando's) asked what's the problem with that, so I provided an example. Now it /was/ extreme -- one would hope it wouldn't ever get quite /that/ bad, but given the context, I guess I agree with Ulrich' comment -- that the resulting filenames could indeed end up rather strange looking. It's certainly something I hadn't thought of until he connected the dots. -- 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
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 18 Dec 2007 23:50:22 + (UTC) Duncan [EMAIL PROTECTED] wrote: Piotr Jaroszyński [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 18 Dec 2007 21:11:20 +0100: On Tuesday 18 of December 2007 20:45:44 Duncan wrote: How about when we have a dozen or so EAPIs active, several of which apply to a specific ebuild? Where is this idea of mixing EAPIs coming from? It really doesn't make much sense. If EAPI is defined as a particular set of features and rules as grouped together under a specific EAPI label (Ciaran's general definition), and is specifically not ordered, as is the case, thus allowing, potentially, multiple EAPIs to evolve in parallel (Grobian's message), as the upthread argues is possible, even likely... But you can't mix features arbitrarily. 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. -- Ciaran McCreesh signature.asc Description: PGP signature
