Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Thomas Pani wrote: > Ciaran McCreesh wrote: >> On Fri, 21 Dec 2007 10:59:14 +0800 >> Zhang Le <[EMAIL PROTECTED]> wrote: >>> And file extension like welcome.html.fr is quite self-explanatory. >>> But an total outsider has no chance to deduce what the 1 in ebuild-1 >>> means on his own. >> A total outsider doesn't need to know. The only people who will be >> dealing with .ebuild-* files are developers and power users. >> > And you are trying to set an even higher barrier for people to reach > that level. How many power users or devs do actually care/know what > EAPI=1 means? http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt We should've made it appear in our front page or GWN. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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. IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 16:09:27 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > IMHO, what is more ridiculous is keeping ask other to be quiet in a > discussion which is supposed to be open to everyone who cares about > it. It's open to anyone who cares about it and is knowledgeable enough to provide informed commentary. Anything else is just noise. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Bo Ørsted Andresen wrote: > On Friday 21 December 2007 05:25:00 Zhang Le wrote: >> The question is really simple. >> Whether we should have two different place to define EAPI? > > We need two places because it wasn't implemented properly in the first place > and we want to retain backwards compatibility for people who use old versions > of portage. The whole point is to keep a sane upgrade path available > indefinitely for people with old versions of portage. Thanks, now I understand this. However, in the first draft the majority part of the glep talks about how to decide EAPI value, which could make others misunderstand the real point behind it. It should be made more clear in the first place, fortunately peper has done that in the new draft of glep-55. BTW, thanks to peper for drafting this glep! However, this doesn't mean I have wholehearted accept this glep. This just means if we ever decided we need ".ebuild-1" suffix, then surely we need such an agreement on how to decide EAPI value. > >> Proponents are trying to prove that we should at least need it be in file >> name. > > We need the file name to change because otherwise old versions of portage > will > try to source the ebuild when the EAPI is unknown. This either blocks new > useful features that will make old versions of portage fail to source them or > results in more bug reports with zillions of dupes (like the bugs in [1]) > because people with ancient versions of portage feel the need to report bug > reports when portage fails after a sync. I think we can educate our user about what is really going on and how to sovle this problem (upgrade PM), by GWN/NEWs on front page/IRC topics/Forums stick threads and so no. > At the very least it means waiting for a year between a release with a > version > of portage that supports this and an EAPI that takes advantage of it. So now > that leaves the question whether we want to change the file name once and > hope that we won't need to do it again or whether we want to use the > technically more flexible way where the file name changes whenever a new EAPI > gets agreed upon. This is another thing needed to be sorted out before we decide to take this suffix approach. > > Or alternatively whether we want to limit ourselves by using an inferior > solution that limits or delays progress considerably and results in more bug > reports with zillions of dupes... Honestly I really don't think our progress would be delayed in any way. The argument to which other approach would delay our progress is that we need to wait people to upgrade their PM. (If this assertion is wrong please ignore th e following sentence) But upgrading PM is very easy, we can use all the channels we have to inform user to upgrade their PM. And people are themselves doing this all the time. BTW, if we decide to use .ebuild-1, will we provide a ebuild file for each EAPI for a specific version of software? I guess probably not, coz that is a huge waste of time and energy. If this is the case, then presumably we only provide new EAPI ebuild for new versions. If a user want to use the new version, he *has* to upgrade his PM so that it could support the new EAPI. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: >> As long as there is an agreement in any given point of time, it is OK. >> Such as, put your EAPI definition on the first line of your ebuild, >> like EAPI="value" > > No good for package managers written before the agreement. Why not force user to upgrade their PM? After all, upgrading is part of our normal life. Now I will try read portage to understand how the metadata generation process works and try to make a doc of it. So before that, I will probably be not so responsive. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 00:59:53 + > Steve Long <[EMAIL PROTECTED]> wrote: >>> It's so that the ebuild's EAPI can be extracted. The way things are >>> currently, there is no way to get an ebuild's EAPI without already >>> knowing its EAPI. >>> >> Like I said, it's trivial to extract a line from the ebuild without >> sourcing. You know it is, and so does everyone else. > > Note *the way things are currently*. If you think this is untrue, > provide an algorithm that will correctly give the EAPI of any current > or future ebuild given that ebuild's filename (hint: you can't). Simple. Whatever you'd like to have in the suffix, we can put it on the first line of the ebuild. Just go and get it, and that's the EAPI. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 16:09:27 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> IMHO, what is more ridiculous is keeping ask other to be quiet in a >> discussion which is supposed to be open to everyone who cares about >> it. > > It's open to anyone who cares about it and is knowledgeable enough to > provide informed commentary. Anything else is just noise. At least not to tell others to be quiet. It is a discussion after all. We can let them become knowledgeable, at least we should try. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: > Still I think we should just postpone this discussion and get a 2008.0 out. And postpone until some doc is out. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 16:55:50 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > Note *the way things are currently*. If you think this is untrue, > > provide an algorithm that will correctly give the EAPI of any > > current or future ebuild given that ebuild's filename (hint: you > > can't). > > Simple. > Whatever you'd like to have in the suffix, we can put it on the first > line of the ebuild. > Just go and get it, and that's the EAPI. Your algorithm: Does not work for existing ebuilds that have implicit EAPI 0. Does not work for existing ebuilds that have explicit EAPI. Does not work for future ebuilds. That's nought for three. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 16:49:10 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > >> As long as there is an agreement in any given point of time, it is > >> OK. Such as, put your EAPI definition on the first line of your > >> ebuild, like EAPI="value" > > > > No good for package managers written before the agreement. > > Why not force user to upgrade their PM? That's a) exactly what we're trying to avoid with EAPIs, b) no good because there isn't a sane way of forcing a package manager upgrade and c) another one of those "wait a year until we can use anything" things. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 16:47:53 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > BTW, if we decide to use .ebuild-1, will we provide a ebuild file for > each EAPI for a specific version of software? The GLEP covers this. There's no sensible way of doing so. > I guess probably not, coz that is a huge waste of time and energy. If > this is the case, then presumably we only provide new EAPI ebuild for > new versions. > > If a user want to use the new version, he *has* to upgrade his PM so > that it could support the new EAPI. Yes, users will have to upgrade at some point. However, EAPI allows them to upgrade in a graceful manner, without stopping the tree from using new features, and without forcing a mass upgrade at any given time. (And yes, we have to be careful with the ebuilds for package managers and some of their direct deps. But that's a very small part of the tree.) -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 17:01:23 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Luca Barbato wrote: > > Still I think we should just postpone this discussion and get a > > 2008.0 out. > > And postpone until some doc is out. There is absolutely no need for such a doc. You don't need to understand every last detail of why things are the way they are in order to use the new format. The only people who need to understand the technicalities are those writing the package managers. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 17:01:23 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Luca Barbato wrote: >>> Still I think we should just postpone this discussion and get a >>> 2008.0 out. >> And postpone until some doc is out. > > There is absolutely no need for such a doc. You don't need to > understand every last detail of why things are the way they are in > order to use the new format. The only people who need to understand the > technicalities are those writing the package managers. And what if that is my real intent? No, just joking, but I am curious. -- 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 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
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Bo Ørsted Andresen wrote: > On Thursday 20 December 2007 20:01:55 Zhang Le wrote: >> IMO, we can not have more than two EAPI's simultaneously. > > That defeats the whole purpose of having EAPIs. Which is to keep a sane > upgrade path... Upgrading happens between two versions. When a new version comes out, we should educate developers about it and encourage them to convert their ebuilds to use new EAPI. When this finished, we can start upgrading to a more new version of EAPI. IMHO, that should be the right way to go. However, I think there is still devs don't know about EAPI-1. If we allow multiple EAPI's to co-exist, do we need a upper limit on that number? Or as many as someone likes? then our tree IMO will become a total mess. People will not remember clearly differences between so many EAPI's. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
Piotr Jaroszyński wrote: > The package manger would have to look for ebuilds in the main > dir and all the subdirs in case it doesn't have/can't use the cache. No, it would have to check only for subdirectories named after known and supported EAPIs. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
As one of those 'users' (an AT actually), I would find having the eapi in the filename quite annoying - especially having several ebuilds in the tree that differ _only_ in their eapi number (and doing different things). It just Seems Wrong - nearly all binary files do versioning/format information inside the files, and one of the main things I like in unix is that file format is *independant* of what you actually name it (a text file can be named *.wibble, or even have no extension at all and nothing will break). Filenames are generally quite mutable - changing the filename is just a single 'mv', whereas if you need to edit the file to change the type that generally requires more effort, you need to think more about what you're doing, and so theres less chance to break stuff (a eapi-1 file accidentally gets moved to eapi-2, lots of stuff breaks, whereas if its in the file you notice you need to edit it to actually make it eapi-2 compliant) And please, please, don't base the decision on who can shout loudest or longest. Think through each option (filename, inside file, metadata, Manifest, directories, seperate db, ...) logically, weigh the pros and cons, and decide on the one that would best fit gentoo on technical grounds, not just on the one backed by the most vocal people. If you make the wrong decision it could seriously screw gentoo over and make it very painful in the future -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 16:55:50 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: >>> Note *the way things are currently*. If you think this is untrue, >>> provide an algorithm that will correctly give the EAPI of any >>> current or future ebuild given that ebuild's filename (hint: you >>> can't). >> Simple. >> Whatever you'd like to have in the suffix, we can put it on the first >> line of the ebuild. >> Just go and get it, and that's the EAPI. > > Your algorithm: > > Does not work for existing ebuilds that have implicit EAPI 0. That's obvious. If no suffix, just treat it as EAPI 0. I thought I don't need to say this explicitly. > > Does not work for existing ebuilds that have explicit EAPI. Even better, since we don't need suffix in the first place. Just define it in ebuild. > > Does not work for future ebuilds. If defined in file does not work, then define in file name doesn't either. They are interchangeable. All could be get before sourcing. I know you'd say people will use all syntaxes to define. But how many are there? EAPI=1, EAPI="1" these are the two ways currently used in tree. A simple qgrep can show that. Two steps can guarantee you get the value 1. strip " 2. get the value -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Simon Cooper wrote: > nearly all binary files do versioning/format information inside the > files Think of different EAPIs as different set of rules for the ebuild contents. If you accept this, you can easily define "new EAPI" as a "new format for ebuilds". It's nice that current EAPI "1" is backwards compatible with the default one, but nobody can guarantee that for future EAPIs. And this is what this thread is about. So, now if it is a different format, it is perfectly reasonable to invent another extension for it, isn't it? > and one of the main things I like in unix is that file format is > *independant* of what you actually name it (a text file can be named > *.wibble, or even have no extension at all and nothing will break). On the contrary, if you rename an ebuild, it doesn't work. > Filenames are generally quite mutable - changing the filename is just a > single 'mv' Only root can mess with files in my $PORTDIR. If you're working as root, you should better pay attention before you move files around. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 16:49:10 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> Ciaran McCreesh wrote: As long as there is an agreement in any given point of time, it is OK. Such as, put your EAPI definition on the first line of your ebuild, like EAPI="value" >>> No good for package managers written before the agreement. >> Why not force user to upgrade their PM? > > That's a) exactly what we're trying to avoid with EAPIs, b) no good > because there isn't a sane way of forcing a package manager upgrade and > c) another one of those "wait a year until we can use anything" things. People have to upgrade even if we adopt the suffix approach, as like I just said. We don't actually need to force people upgrade their PM, if they need new version of software whose ebuild is in new EAPI, they will want to upgrade their PM themselves, either way. -- 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)
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
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Fri, 21 Dec 2007 12:27:31 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's. > > What? All two of them that you need to know about, where the second > one is the first one with three new features? Sorry, I made you confused. I was not talking about now, I am talking about the consequences of this glep. At least we already have a EAPI 2 tracker in our bugzilla. I am afraid we lose the control of EAPI development. or maybe I just over reacted, but you get my point. We need to make a formal development model and development cycle of EAPI. We need to make sure all developers and as many users as possible to know it. I have just created a page of EAPI on wikipedia, let's improve it together. http://en.wikipedia.org/wiki/EAPI -- 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 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] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Zhang Le wrote: > I have just created a page of EAPI on wikipedia, let's improve it together. > http://en.wikipedia.org/wiki/EAPI And later convert it to guidexml and put it on gentoo.org, of course. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Zhang Le wrote: > Zhang Le wrote: >> I have just created a page of EAPI on wikipedia, let's improve it together. >> http://en.wikipedia.org/wiki/EAPI > > And later convert it to guidexml and put it on gentoo.org, of course. Wikipedia uses GFDL while we use CC-BY-SA, so no, you can't do that before the Wikimedia Foundation manages to persuade FSF to change GFDL. Cheers, -jkt -- cd /local/pub && more beer > /dev/mouth signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: > > > > Your algorithm: > > > > Does not work for existing ebuilds that have implicit EAPI 0. > > That's obvious. If no suffix, just treat it as EAPI 0. > I thought I don't need to say this explicitly. '# Copyright 1999-2007 Gentoo Foundation' Is that an EAPI? of course it is not, are you going to hardcode every possible ebuild header in your stupid _hack_ ? > > > > Does not work for existing ebuilds that have explicit EAPI. > > Even better, since we don't need suffix in the first place. Just define it in > ebuild. What? > > > > Does not work for future ebuilds. > > If defined in file does not work, then define in file name doesn't either. > They are interchangeable. No, they are not. > All could be get before sourcing. > I know you'd say people will use all syntaxes to define. But how many are > there? EAPI=1, EAPI="1" these are the two ways currently used in tree. > A simple qgrep can show that. > Two steps can guarantee you get the value > 1. strip " > 2. get the value And then you are stuck FOREVER into defining EAPI as a variable. You clearly haven't read anything on this thread. I suggest you go and do so before making a fool of yourself again. Please. Please guys, keep in mind that the fact that some of you understand what a filename is and are able to provide simple commands that extract a particular line from a file does not entitle you with the knowdledge required to contribute something useful to this discussion. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpq7ujd1zNsE.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote: > Ciaran McCreesh wrote: > > On Sat, 22 Dec 2007 16:09:27 +0800 > > Zhang Le <[EMAIL PROTECTED]> wrote: > >> IMHO, what is more ridiculous is keeping ask other to be quiet in a > >> discussion which is supposed to be open to everyone who cares about > >> it. > > > > It's open to anyone who cares about it and is knowledgeable enough to > > provide informed commentary. Anything else is just noise. > > At least not to tell others to be quiet. > It is a discussion after all. > We can let them become knowledgeable, at least we should try. Heh... unfortunately this is gentoo and this behaviour is tolerated. Try to go with this same thing to the lkml[*1*]. Ask them to teach you C so you can contribute with your opinion to every single patch and design decision that is made. Then tell them they should teach you stuff about OS design because you _are_entitled_ an opinion, then [then, sane people see how this approach gets silly] - ferdy 1 - And if you do so, please share Message-IDs, it'll make a great laugh. -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpJPPltHYsaK.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Sat, Dec 22, 2007 at 07:09:30AM +, Ciaran McCreesh wrote:
> On Sat, 22 Dec 2007 03:41:02 +0200
> Petteri Räty <[EMAIL PROTECTED]> wrote:
> > Piotr Jaroszyński kirjoitti:
> > > This GLEP proposes usage of EAPI-suffixed file extensions for
> > > ebuilds (for example, foo-1.2.3.ebuild-1).
> >
> > It seems many people don't like the idea of having it in the filename
> > but how about having subdirectories for different eapis. This should
> > even be faster for the package manager as it can just ignore the
> > directories it can't understand instead of having to parse the file
> > names.
> >
> > example:
> >
> > ${PORTDIR}///eapiX/
>
> In terms of what it does and doesn't allow, this one's equivalent. But
> it has some new disadvantages:
>
> * It's several more directory reads. This is a measurable performance
> hit on something that's already i/o bound.
Among other things, because readdirs cannot be neither readahead nor
'advised'. Which is STUPIDLY slow. So adding yet another directory to
the hierarchy is quite silly.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
pgp2k93LGjnu1.pgp
Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 17:49:32 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > When a new version comes out, we should educate developers about it > and encourage them to convert their ebuilds to use new EAPI. No, we shouldn't. People should use new EAPIs as necessary, not as soon as possible. > If we allow multiple EAPI's to co-exist, do we need a upper limit on > that number? No. Package managers have to support all EAPIs that have ever been around anyway to deal with installed packages. > Or as many as someone likes? then our tree IMO will become a total > mess. People will not remember clearly differences between so many > EAPI's. They don't need to. They just need to be familiar with recent EAPIs. The only people who have to keep track of all of them are the package manager people. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 09:53:48 + Simon Cooper <[EMAIL PROTECTED]> wrote: > As one of those 'users' (an AT actually), I would find having the eapi > in the filename quite annoying - especially having several ebuilds in > the tree that differ _only_ in their eapi number (and doing different > things). It just Seems Wrong Which is why the GLEP disallows it... > Filenames are generally quite mutable - changing the filename is just > a single 'mv', whereas if you need to edit the file to change the type > that generally requires more effort, you need to think more about what > you're doing, and so theres less chance to break stuff (a eapi-1 file > accidentally gets moved to eapi-2, lots of stuff breaks, whereas if > its in the file you notice you need to edit it to actually make it > eapi-2 compliant) I suggest you try using gcc to compile a C++ file with a .c file extension... > And please, please, don't base the decision on who can shout loudest > or longest. Think through each option (filename, inside file, > metadata, Manifest, directories, seperate db, ...) logically, weigh > the pros and cons, and decide on the one that would best fit gentoo > on technical grounds, not just on the one backed by the most vocal > people. If you make the wrong decision it could seriously screw > gentoo over and make it very painful in the future Oh, we did all that long before the GLEP was written. The filename solution is by far the best -- it's the only one that hasn't had any technical objections raised to it. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 17:37:37 +0800 Zhang Le <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > On Sat, 22 Dec 2007 17:01:23 +0800 > > Zhang Le <[EMAIL PROTECTED]> wrote: > >> Luca Barbato wrote: > >>> Still I think we should just postpone this discussion and get a > >>> 2008.0 out. > >> And postpone until some doc is out. > > > > There is absolutely no need for such a doc. You don't need to > > understand every last detail of why things are the way they are in > > order to use the new format. The only people who need to understand > > the technicalities are those writing the package managers. > > And what if that is my real intent? > No, just joking, but I am curious. Then you're up for a long hard "working it out for yourself and asking lots of intelligent, well thought out questions (because any other kind won't get answers) to people who've already done it" struggle. You have the benefit of PMS to tell you more or less what the package manager / ebuild API is, but you're on your own for the rest. -- Ciaran McCreesh -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Saturday 22 of December 2007 09:09:27 Zhang Le 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. > > IMHO, what is more ridiculous is keeping ask other to be quiet in a > discussion which is supposed to be open to everyone who cares about it. I am not asking anyone to be quiet, but it's probably the best way to go if one doesn't care enough to do own research before asking to be educated. -- Best Regards, Piotr Jaroszyński -- [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
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: > On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: >> All could be get before sourcing. >> I know you'd say people will use all syntaxes to define. But how many are >> there? EAPI=1, EAPI="1" these are the two ways currently used in tree. >> A simple qgrep can show that. >> Two steps can guarantee you get the value >> 1. strip " >> 2. get the value > > And then you are stuck FOREVER into defining EAPI as a variable. > And with the proposed GLEP you are stuck FOREVER into defining EAPI as part of the filename. What's the difference? > You clearly haven't read anything on this thread. I suggest you go and > do so before making a fool of yourself again. Please. I doubt that they have failed to see that this reply has been made before. Very little has been posted in the last day on this thread that hasn't already been posted the day before. The issue isn't that people are too dumb to realize the limitations of putting "EAPI=foo" in their ebuilds - the issue is that many don't believe that this is much of a limitation. However, nobody wants to stop replying because they're probably concerned that their ignoring this thread will be accepted as evidence of acceptance of the proposal. > > Please guys, keep in mind that the fact that some of you understand what > a filename is and are able to provide simple commands that extract a > particular line from a file does not entitle you with the knowdledge > required to contribute something useful to this discussion. This really isn't helpful. It is essentially an ad-hominum argument. The fundamental issue is that there is a disagreement over whether leaving things as they are currently is a major problem. If others don't have the knowledge necessary to contribute something useful then take the time to educate them - don't tell them to just be quiet. The number of replies in this thread obviously indicates that we're not talking about 1-2 people who aren't quite sure what is going on and 200 people that clearly agree with the merits of this proposal. If so many people can't see the value in this GLEP then perhaps it isn't adequately explained? As I see it, the only real advantage of changing filenames vs a variable with formatting requirements (thus allowing it to be scanned without sourcing the ebuild) seems to be that it will prevent current package managers from breaking when they source an ebuild due to new global functions. The only other objection I've seen raised is that the variable approach limits your future options regarding content - but I don't see that as being really any worse than limiting the filename. Either way its a few bytes in a particular spot on the disk - why is one better than the other? I'm actually warming up to this proposal a little, but those in favor of it would do well to address concerns and discuss them with those who raise them (possibly by irc/off-list-email as needed) and not just tell them to be quiet about it. The goal isn't to bash everybody in to submission within 2 days so that the GLEP can get approved - the goal is to gather input so that the GLEP can be as good as possible when it is approved. You don't need to completely agree with your critics to at least consider their objections. smime.p7s Description: S/MIME Cryptographic Signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/22, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > The filename solution is by far the best -- it's the only one that > hasn't had any technical objections raised to it. And can you remind us what technical objection, if any, has been raised against the "EAPI set in contents with enough syntaxic restrictions to allow its extraction without sourcing, and the files names extension changing only if this rules have to change" alternative? It's a bit annoying to see EAPI-in-contents solutions bashed everywhere in this thread under the pretext of backward or forward compatibility, whereas this points has been adressed very early in the discussion. So, once more to make it clear: yes, the current ".ebuild" extension would have to change into ".something" if we want to introduce such a solution without waiting N months. The difference with ".ebuild-$EAPI" being that ".something" would then stay unchanged for numerous later EAPIs (until some unlikely conditions are met, like a switch away from Bash format). -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP 55] EAPI subdirectories instead of file name suffixes
On Saturday 22 of December 2007 10:50:40 Jan Kundrát wrote: > Piotr Jaroszyński wrote: > > The package manger would have to look for ebuilds in the main > > dir and all the subdirs in case it doesn't have/can't use the cache. > > No, it would have to check only for subdirectories named after known and > supported EAPIs. Not really, we still want to show ebuilds with unsupported EAPI as being masked, but I agree it will have to check only eapiX subdirs. It's still a performance hit though. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Hello, I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. As I still didn't get the "ok to commit" from our glep folks, read the most current version here: http://dev.gentoo.org/~peper/glep-0055.html http://dev.gentoo.org/~peper/glep-0055.txt -- Best Regards, Piotr Jaroszyński GLEP: 55 Title: Use EAPI-suffixed ebuilds (.ebuild-EAPI) Version: $Revision: $ Last-Modified: $Date: $ Author: Piotr Jaroszyński <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17-Dec-2007 Post-History: 17-Dec-2007, 22-Dec-2007 "A little learning is a dangerous thing; drink deep, or taste not the Pierian spring: there shallow draughts intoxicate the brain, and drinking largely sobers us again." -- Alexander Pope, An Essay on Criticism Abstract This GLEP proposes usage of EAPI-suffixed file extensions for ebuilds (for example, foo-1.2.3.ebuild-1). Problem === The current way of specifying the EAPI in ebuilds is flawed. In order to get the EAPI the package manager needs to source the ebuild, which itself needs the EAPI in the first place. Otherwise it imposes a serious limitation, namely every ebuild, using any of the future EAPIs, will have to be source'able by old package managers and hence there is no way to: * Change behaviour of inherit in any way (for example, to extend or change eclass functionality). * Add new global scope functions in any sane way. * Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [#GLEP54]_. Abstract solution = A solution to this problem has to lift those limitations and the only way to do it is to make the EAPI of an ebuild available to the package managers in a way that doesn't require them to source the ebuild. Another important requirement is for the solution to be backward compatible, which has the pleasant side-effect of making the solution applicable in the Gentoo tree right away. Opposed to waiting an arbitrary amount of time, which is never long enough anyway, as the issues listed on the common portage problems page - [#PortageProblems]_ - show. Proposed solution = The proposed solution is to use EAPI-suffixed file extensions for ebuilds. This allows package managers to trivially read the EAPI from the ebuild filename. It is also backward compatible, because currently ebuilds are recognised by the ``.ebuild`` file extension and hence EAPI-suffixed ebuilds are simply ignored by the package managers. Specification = 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. Examples: * ``pkg-1.ebuild``, no EAPI set inside the ebuild pre-source EAPI defaults 0, post-source EAPI defaults to pre-source EAPI. EAPI 0 is used. * ``pkg-2.ebuild-1``, no EAPI set inside the ebuild pre-source EAPI is 1, post-source EAPI defaults to pre-source EAPI. EAPI 1 is used. * ``pkg-3.ebuild``, ``EAPI="1"`` pre-source EAPI defaults to 0, post-source EAPI is 1. EAPI 1 is used. * ``pkg-4.ebuild-2``, ``EAPI="1"`` pre-source EAPI is 2, post-source EAPI is 1. EAPI 1 is used, but note that one should **never** explicitly set both EAPIs to different values. * ``pkg-5.ebuild-2``, no EAPI set inside the ebuild, package manager not supporting EAPI 2 pre-source EAPI is 2, post-source EAPI is never checked. ebuild masked because of the unsupported pre-source EAPI. * ``pkg-6.ebuild``, ``EAPI="2"``, package manager not supporting EAPI 2 pre-source EAPI defaults to 0, post-source EAPI is 2 (assuming the package manager didn't die when sourcing the ebuild thinking that EAPI 0 is used). ebuild masked because of the unsupported post-source EAPI. Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing to provide backward compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-ve
Re: [gentoo-dev] EAPI placement
On Mittwoch, 12. Dezember 2007, Santiago M. Mola wrote: > Nobody said that eclasses can't use new features. Using new features in ebuilds or eclasses relates. EAPI A using ebuild with EAPI B using eclass (but not defining any EAPI) is your hard nut. Shouldn't happen, but will. And bugs in eclasses unfortunately don't have a minor impact. > Just that they > cannot _set_ EAPI or assume they are working with any EAPI. And I say they can - under the condition that you have a defined subset of ebuilds belonging to that eclass. > Yep, that issue should be addresses as it is in paludis and pkgcore. Neither one is Gentoo's package manager Please spare me an answer. :) Carsten signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] EAPI placement
On Mittwoch, 12. Dezember 2007, Ciaran McCreesh wrote:
> On Wed, 12 Dec 2007 23:14:24 +0100
> There is no way for an eclass to throw an error. Nor, with the current
> way Portage implements EAPI, is there a way to add such a way.
It's not perfect, but
_pkg_setup() {
something_wrong && die
}
should work reasonably well.
> It's in PMS. svn co http://svn.repogirl.net/pms for a copy.
Right. But when you think every dev will read the PMS to find out what's fine
to do and what not for N++ EAPIs again and again, while he wants only a short
list of do's and don'ts, your bathing temperature is far above average.
What I do think - and no, I won't read this rediculous large
category/ebuild-x.y-rN-my.local.version-too-much-coffein-drinks.ebuild-epaiN-anyone-else-with-a-stupid-idea
thread - is, that EPAI changes and there implications apparently have not
been well thought out and the best we can do is to ensure there are as few
eclass/ebuild-relating differing EAPIs as possible.
Carsten
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: > On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote: >> Ciaran McCreesh wrote: >>> On Sat, 22 Dec 2007 16:09:27 +0800 >>> Zhang Le <[EMAIL PROTECTED]> wrote: IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. >>> It's open to anyone who cares about it and is knowledgeable enough to >>> provide informed commentary. Anything else is just noise. >> At least not to tell others to be quiet. >> It is a discussion after all. >> We can let them become knowledgeable, at least we should try. > > Heh... unfortunately this is gentoo and this behaviour is tolerated. Try > to go with this same thing to the lkml[*1*]. Ask them to teach you C so > you can contribute with your opinion to every single patch and design > decision that is made. Then tell them they should teach you stuff about > OS design because you _are_entitled_ an opinion, then [then, sane > people see how this approach gets silly] I have mailed my patch to LKML. So I know the situation there. Linux kernel community has a kernelnewbie mailing list. But we don't have one. We don't even have enough docs to educate our future potential package manager maintainer. Note I am not blaming anyone there. Let's start from ourselves. -- 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)
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
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Richard Freeman wrote: > Fernando J. Pereda wrote: >> On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: >>> All could be get before sourcing. >>> I know you'd say people will use all syntaxes to define. But how many are >>> there? EAPI=1, EAPI="1" these are the two ways currently used in tree. >>> A simple qgrep can show that. >>> Two steps can guarantee you get the value >>> 1. strip " >>> 2. get the value >> And then you are stuck FOREVER into defining EAPI as a variable. >> > > And with the proposed GLEP you are stuck FOREVER into defining EAPI as > part of the filename. What's the difference? Ditto. > >> You clearly haven't read anything on this thread. I suggest you go and >> do so before making a fool of yourself again. Please. If I haven't read previous posts, then I would not participate in this discussion in the first place. I have read a lot and feel like I should say something so that my previous reading are not totally wasted. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: > On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: >>> Your algorithm: >>> >>> Does not work for existing ebuilds that have implicit EAPI 0. >> That's obvious. If no suffix, just treat it as EAPI 0. >> I thought I don't need to say this explicitly. > > '# Copyright 1999-2007 Gentoo Foundation' > > Is that an EAPI? of course it is not, are you going to hardcode every > possible ebuild header in your stupid _hack_ ? We are doing this in almost every file format we are using. ELF(exacutable and linkable format) JPEG GIF ... If this is stupidity, then we are all stupid. >>> Does not work for future ebuilds. >> If defined in file does not work, then define in file name doesn't either. >> They are interchangeable. > > No, they are not. Why not? Please always add a reason, which is helpful to the discussion. Thanks! -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Jan Kundrát wrote: > Zhang Le wrote: >> Zhang Le wrote: >>> I have just created a page of EAPI on wikipedia, let's improve it together. >>> http://en.wikipedia.org/wiki/EAPI >> And later convert it to guidexml and put it on gentoo.org, of course. > > Wikipedia uses GFDL while we use CC-BY-SA, so no, you can't do that > before the Wikimedia Foundation manages to persuade FSF to change GFDL. > Sorry, I overlooked the license problem. But anyway we need such a doc. We can move to gentoo-wiki.com where the license by default is public domain. http://gentoo-wiki.com/EAPI -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Piotr Jaroszyński wrote: I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. As I still didn't get the "ok to commit" from our glep folks, read the most current version here: http://dev.gentoo.org/~peper/glep-0055.html http://dev.gentoo.org/~peper/glep-0055.txt Haven't read the previous discussion, apologies if this has been clarified already, but I think it would be good to answer the following question in the GLEP: Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI inside the ebuild? It seems that one approach you might take is to move the EAPI selection into the filename and remove it from the ebuild itself, and it's not clear to me why your proposal isn't exactly that. Thanks, Daniel -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 17:49:32 +0800 > Zhang Le <[EMAIL PROTECTED]> wrote: >> When a new version comes out, we should educate developers about it >> and encourage them to convert their ebuilds to use new EAPI. > > No, we shouldn't. People should use new EAPIs as necessary, not as soon > as possible. Then we should at least provide them a doc first and let them know when the doc is already. So they can learn when they feel like they should learn. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Saturday 22 of December 2007 18:56:12 Daniel Drake wrote: > Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI > inside the ebuild? > > It seems that one approach you might take is to move the EAPI selection > into the filename and remove it from the ebuild itself, and it's not > clear to me why your proposal isn't exactly that. That's the goal, yes. The "Specification" part shows how to do that in a backward compatible way and the "Application" part says how is the new format supposed to be used. But seeing it's not clear enough I will look into it. -- Best Regards, Piotr Jaroszyński -- [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: .ebuild[-] Where: is the full package name, version, and revision, as in man 5 ebuild. - is optional. 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
[gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Daniel Drake <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 22 Dec 2007 17:56:12 +: >> http://dev.gentoo.org/~peper/glep-0055.html >> >> http://dev.gentoo.org/~peper/glep-0055.txt > > Haven't read the previous discussion, apologies if this has been > clarified already, but I think it would be good to answer the following > question in the GLEP: > > Why (in terms of your GLEP) are you still allowing ebuilds to set EAPI > inside the ebuild? > > It seems that one approach you might take is to move the EAPI selection > into the filename and remove it from the ebuild itself, and it's not > clear to me why your proposal isn't exactly that. Actually, that was clarified in this new version. Is the following (from the Application section) sufficient? Maybe pre-source EAPI and post- source EAPI aren't clearly enough defined? (Their def is in the first paragraph under specification.) Note that the developers should only set the pre-source EAPI. The process described above is only necessary to avoid undefined behaviour in corner cases and to retain backwards compatibility. QA tools may warn if the post-source EAPI is set at all, thus helping with the transition to the new format. As I had read the first version, that leapt out at me. Did you just miss it or do you still believe it needs clarified further? -- 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] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sun, Dec 23, 2007 at 01:14:46AM +0800, Zhang Le wrote: > Fernando J. Pereda wrote: > > On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote: > >> Ciaran McCreesh wrote: > >>> On Sat, 22 Dec 2007 16:09:27 +0800 > >>> Zhang Le <[EMAIL PROTECTED]> wrote: > IMHO, what is more ridiculous is keeping ask other to be quiet in a > discussion which is supposed to be open to everyone who cares about > it. > >>> It's open to anyone who cares about it and is knowledgeable enough to > >>> provide informed commentary. Anything else is just noise. > >> At least not to tell others to be quiet. > >> It is a discussion after all. > >> We can let them become knowledgeable, at least we should try. > > > > Heh... unfortunately this is gentoo and this behaviour is tolerated. Try > > to go with this same thing to the lkml[*1*]. Ask them to teach you C so > > you can contribute with your opinion to every single patch and design > > decision that is made. Then tell them they should teach you stuff about > > OS design because you _are_entitled_ an opinion, then [then, sane > > people see how this approach gets silly] > > I have mailed my patch to LKML. So I know the situation there. > Linux kernel community has a kernelnewbie mailing list. But we don't have one. > We don't even have enough docs to educate our future potential package manager > maintainer. Note I am not blaming anyone there. > Let's start from ourselves. Their docs are usually the source. Source that you still haven't studied and keep moaning because we don't want to explain the process as if this were primary school. Go and read the source, study and understand it. - ferdy -- Fernando J. Pereda Garcimartín 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgptFXjybjV3b.pgp Description: PGP signature
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: > > .ebuild[-] 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
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: > Their docs are usually the source. And files under Documentation And they have a policy which requires them to write a doc for any new feature/functionality to be accepted -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: > On Sat, 22 Dec 2007 04:24:06 +0100 > Luca Barbato <[EMAIL PROTECTED]> wrote: >> Not if we move the rsync path properly so >> >> - older pm sync to a minimal try apt to upgrading portage and nothing >> else >> >> - newer sync to the full tree now supporting the newer an better and >> honey and milk eapi. > > ...and do it again every three months when a new EAPI comes along. > Great... > I don't see problems in doing that... and NO, a new eapi must not appear every week. 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: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 10:12:51 -0500 Richard Freeman <[EMAIL PROTECTED]> wrote: > > And then you are stuck FOREVER into defining EAPI as a variable. > > And with the proposed GLEP you are stuck FOREVER into defining EAPI as > part of the filename. What's the difference? No you aren't. That is the difference. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Sat, 22 Dec 2007 16:23:13 +0100 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > On 2007/12/22, Ciaran McCreesh <[EMAIL PROTECTED]> > wrote: > > The filename solution is by far the best -- it's the only one that > > hasn't had any technical objections raised to it. > > And can you remind us what technical objection, if any, has been > raised against the "EAPI set in contents with enough syntaxic > restrictions to allow its extraction without sourcing, and the files > names extension changing only if this rules have to change" > alternative? a) It's a massive restriction on what future ebuilds can do. b) It's a massive restriction on what current ebuilds can do. 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. d) It introduces a new prepass parse layer to an already complex process. e) The Portage guys said no to it. > So, once more to make it clear: yes, the current ".ebuild" extension > would have to change into ".something" if we want to introduce such a > solution without waiting N months. The difference with > ".ebuild-$EAPI" being that ".something" would then stay unchanged for > numerous later EAPIs You keep saying that like *.ebuild-3 and *.ebuild-4 are massively different. They're not. They're the same extension, decorated slightly differently. > (until some unlikely conditions are met, like a switch away from Bash > format). Or until we do something about eclasses and EAPIs, or until we do something about storing metadata outside of the ebuilds themselves... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] renaming of the 'gimli' SVN repo
This email probably isn't necessary, and most people won't care about this. However, sending it was one of robbat2's terms for renaming this SVN repo, so here it is :P The current repo name 'gimli' was the original name of the project a long time ago. The name of the project is now Scire, and we've gotten tired of looking at the old repo name. If you have this repo checked out, you can either check it out again, or use one of the following commands: svn switch --relocate svn+ssh://svn.gentoo.org/var/svnroot/gimli svn+ssh://svn.gentoo.org/var/svnroot/scire (for devs) OR svn switch --relocate http://anonsvn.gentoo.org/repositories/gimli http://anonsvn.gentoo.org/repositories/scire (for users of anonsvn) Thanks. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
