Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Tue, 1 Jan 2008 05:50:11 +0100 Marius Mauch [EMAIL PROTECTED] wrote: You pretty much have to have a way of mapping an EAPI version onto an absolute version if you want to handle it sanely. Right, and that's likely to cause a mess in the long run IMO. Eh, it's already necessary if package managers want to support things like CPAN natively. It's not too big a deal. Mmm, no. You have some concept of a superset of all supported naming rules, then refine once you've extracted the EAPI. Assuming the current package manager supports all used EAPIs, otherwise a formerly invalid name could still break it. 'Twould just have to ignore them. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sat, 22 Dec 2007 16:43:10 +0100 Piotr Jaroszyński [EMAIL PROTECTED] wrote: Hello, I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. Still doesn't address my concerns, namely: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) - doesn't mention compability issues on the dev side (minor) Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 31 Dec 2007 15:33:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) That already happened with EAPI 1 and slot deps. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 12:03:12 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Thu, 27 Dec 2007 23:26:27 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? The restricted definition is certainly OK, but I'm not convinced that the restriction is necessary. There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Marius -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 31 Dec 2007 15:46:06 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? You pretty much have to have a way of mapping an EAPI version onto an absolute version if you want to handle it sanely. Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Mmm, no. You have some concept of a superset of all supported naming rules, then refine once you've extracted the EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Monday 31 of December 2007 15:33:51 Marius Mauch wrote: Still doesn't address my concerns, namely: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) And what is the reason for not doing exactly that? Seems logical to me. And btw. slot deps added in EAPI 1 seems to have similiar impact, you can't use them in ebuilds using EAPI 0 nor in profiles/. - doesn't mention compability issues on the dev side (minor) Aren't new EAPIs introducing the same problem already? Devs should use up to date tools, and especially the devs running some checks on the whole tree. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 31 Dec 2007 15:09:33 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 15:46:06 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? You pretty much have to have a way of mapping an EAPI version onto an absolute version if you want to handle it sanely. Right, and that's likely to cause a mess in the long run IMO. Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Mmm, no. You have some concept of a superset of all supported naming rules, then refine once you've extracted the EAPI. Assuming the current package manager supports all used EAPIs, otherwise a formerly invalid name could still break it. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 31 Dec 2007 14:40:57 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 15:33:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) That already happened with EAPI 1 and slot deps. Not really. Just because slot deps are included in EAPI 1 doesn't mean that they have to be supported everywhere. The complete atom specification should be a separate versioned document, and EAPI references version X of it and the profile specification references version Y, simple as that. Marius -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 13:25:13 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). Possibly. Currently there's simply no way of doing it, nor of using non-EAPI-0 features anywhere in profiles (you can't, for example, use slot deps in package.mask). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 27 Dec 2007 23:26:27 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? The restricted definition is certainly OK, but I'm not convinced that the restriction is necessary. There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 28, 2007 1:28 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Fri, 28 Dec 2007 13:25:13 +0100 Santiago M. Mola [EMAIL PROTECTED] wrote: On Dec 28, 2007 1:03 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. Ditto for naming rules. Errr... so should we use new files in profiles for such new formats? (for example, p.masking an ebuild with a new version format). Possibly. Currently there's simply no way of doing it, nor of using non-EAPI-0 features anywhere in profiles (you can't, for example, use slot deps in package.mask). It'd be nice to agree a new profile format before accepting version format changes. In the case of slot deps, it'd be desirable to use them in package.mask, just desirable. But with version format changes we're introducing ebuilds which can't be handled in package.mask, that's a great loss of functionality. GLEPs 54 and 55 could wait until we have figured out how to apply them properly and without loss of current functionality. -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 17:22:22 +0100 Luca Barbato [EMAIL PROTECTED] wrote: I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo Unfortunately the emerge --eapi $foo part would be passed as a single argument to /usr/bin/env, therefore can't work. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 09:55:06 + Ciaran McCreesh [EMAIL PROTECTED] wrote: Stuck ranges into metadata.xml for which EAPIs applied? No package manager required information can be in XML format. Says who? Us. We can change that, if we decide it's the best answer. =) Say the Portage people for the past lots of years. I assume you're referring to some statements I and maybe Nick made several years ago, I don't think Brian, Jason or Zac ever really thought about it. I can only speak for myself, but those past statements were mostly due to experiences made with glsa-check and issues in the python/pyxml relationship (in 2003), things may have changed since then so those statements could be re-evaluated. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 27 Dec 2007 21:28:41 +0100 Michael Haubenwallner [EMAIL PROTECTED] wrote: This also could be done as (using 'ebuild' instead of 'emerge') #! /usr/bin/env ebuild.1 and PM could provide some 'ebuild.1' executable, at the bare mimimum doing nothing but #! /bin/sh exec ebuild --eapi 1 $@ But *why*? We've finally almost gotten people away from installing things using ebuild. Why on earth would we want to bring it back? The correct way to install a package is through the nice, friendly, mask checking, dependency resolving package manager frontend. There is no correct action that can be taken when an ebuild is executed on its own, so ebuilds shouldn't be executable on their own. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Marius Mauch wrote: On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 2007-12-27 at 20:48 +0100, Marius Mauch wrote: On Thu, 20 Dec 2007 17:22:22 +0100 Luca Barbato [EMAIL PROTECTED] wrote: I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo Unfortunately the emerge --eapi $foo part would be passed as a single argument to /usr/bin/env, therefore can't work. This also could be done as (using 'ebuild' instead of 'emerge') #! /usr/bin/env ebuild.1 and PM could provide some 'ebuild.1' executable, at the bare mimimum doing nothing but #! /bin/sh exec ebuild --eapi 1 $@ /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Marius Mauch wrote: On Thu, 20 Dec 2007 08:10:13 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ok, that seems a fine definition of what an eapi is. Everybody agrees on it? Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? lu Logical and proper to me. -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 27, 2007 11:40 PM, Doug Klima [EMAIL PROTECTED] wrote: [... EAPI is stuff PM supports/exports to the ebuild ...] Logical and proper to me. Actually, when I'm asked what EAPI is, I just say EAPI is a standard definition for the ebuild structure, implying supporting features from the package manager. Most of the time, the user is happy with the answer ;-) Wkr, Sven Vermeulen -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/23, Ciaran McCreesh [EMAIL PROTECTED] wrote: a) It's a massive restriction on what future ebuilds can do. - it handles a reasonnable range of likely future EAPIs, - it includes the extension changes when the way to extract EAPI has to change to avoid bounding future EAPIs to this range. b) It's a massive restriction on what current ebuilds can do. Current ebuilds are the one with the .ebuild extension. I'm not proposing any change to the way they are handled. Now, if you mean that there are some stuffs allowed in .ebuild files which would no more be allowed in the .something files, then yes: it introduces some restrictions on how the EAPI is declared. That's how it works. It has yet to be shown that this restrictions fordbids anything else than some pointless code (like setting EAPI depending on $PV), and furthermore that this code would, at the contrary, play well with the GLEP 55 approach (obviously not the case with the previous pointless example). 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. Devs are already used to follow numerous conventions in the way they format their ebuilds. While this restriction is more than a convention, I assume that's how it will be followed by many people: just doing things the way they are in skel.something. And for those who happen to break the rule because they edited a .something file without knowing what it was, they would learn as soon as they test/use their file (no need to wait for the repoman step, it would be checked whenever the ebuild is sourced). 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. 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. [1] http://thread.gmane.org/gmane.linux.gentoo.devel/29512 You keep saying that like *.ebuild-3 and *.ebuild-4 are massively different. They're not. They're the same extension, decorated slightly differently. To me they look different enough that it's worth avoiding them if possible (especialy considering the decoration is not just an integer). I absolutly agree that it's a futile and subjective objection to GLEP 55, but so far, and until you answer to what i've left open above, it's the only aspect on which i can think one solution is better than the other. (until some unlikely conditions are met, like a switch away from Bash format). Or until we do something about eclasses and EAPIs, If you're not more specific about this something, it's hard to say what solution will handle it best. For example, it could be nice that some ebuilds which are just instanciation of an eclass (like the vim-spell-* ones) let their eclass decide what EAPI it needs. That's something which could be handled nicely by a backward-compatible extension of the EAPI-in-contents approach: # Copyright... eapi inherited:vim-spell-2 VIM_SPELL_LANGUAGE=French inherit vim-spell-2 (the -2 here is not a specific EAPI, it's just that the vim-spell eclass already exists and that it would not be a good idea to apply the needed changes to it) PMs which know how to handle such redirection would then go look for an EAPI declared in the eclass before sourcing the whole thing. PMs which don't yet would see it as an unsupported EAPI and stop there. 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. or until we do something about storing metadata outside of the ebuilds themselves... # Copyright... eapi from-external-metadatas ... I agree there's an unecessary performance impact on doing that though, so you're right that it's a case where changing the file extension would be better. The EAPI declaration would be moved together with the
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)
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] [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] [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
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] 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] [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] [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
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)
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: 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] [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] 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
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: [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
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] [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
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 08:43:43 Richard Freeman wrote: Ciaran McCreesh wrote: Please don't comment any further until you understand how this whole thing works. CON: Yet another value to be parsed out of an increasingly-complex filename. Doesn't look pretty :) Taste is a matter of opinion. I happen to like eapi-1 in the filename so I know a bit about the ebuild before looking through its contents. Makes a low-level detail more visible to users. 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. This isn't a CON, it is actually a PRO because old PMs won't recognize the new format and everyone will be happy. (something not so easy with the other solutions.) -- 2.6.23-gentoo-r3 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh a écrit : Developers have to know about EAPIs. It's part of knowing how to write ebuilds. There's no way around that -- if you're writing ebuilds, you have to know what you are and aren't allowed to do in those ebuilds. Then please try to keep things simple :) The majority of devs don't want to know how portage or paludis work internally, that's not what interests most of us. 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? Cheers, Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:
I'm thinking about having them embedded in the comment as first line as
something like
#!/usr/bin/env emerge --eapi $foo
OT: It actually works adding this first line and do chmod +x foo.ebuild:
#! /usr/bin/env ebuild
Then you can do: ./foo.ebuild {digest,install,merge,whatever}
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 14:29:25 +0100 Rémi Cardona [EMAIL PROTECTED] wrote: Ciaran McCreesh a écrit : Developers have to know about EAPIs. It's part of knowing how to write ebuilds. There's no way around that -- if you're writing ebuilds, you have to know what you are and aren't allowed to do in those ebuilds. Then please try to keep things simple :) *Using* EAPIs is simple. *Designing* them, not so much. 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. 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. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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. 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. 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. 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... [1] http://www.gentoo.org/proj/en/portage/doc/common-problems.xml -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 17:14:52 Thomas Pani wrote: Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? No, we're not Debian, thank god. I thought the wait 1+ year policy changed? Again citing Ciaran: That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked. [2] It has changed as long as you don't introduce features that makes old versions of portage fail to source the ebuild. EAPI=1 didn't do that. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Friday 21 December 2007 05:46:35 Josh Saddler wrote: Who cares? Gentoo uses the ebuild/bash-with-shebang format. If you're trying to shove in something outside of that, that would be a package manager-specific format. Like XML-stuff (that can't include the shebang or EAPI=foo at the top) specifically for, say, Paludis. GLEP means Gentoo Linux Enhancement Proposal. It was proposed to enhance Gentoo... Paludis already supports this kind of thing for usage outside gentoo-x86. That has no relevance to Gentoo unless the GLEP gets approved... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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... -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 22:33:25 Joe Peterson wrote: Technical reasons to avoid the filename are: 2) Having the same info in more than one place is bad (requiring extra repoman checks and the potential for ambiguity). As opposed to adding checks to make sure that obtaining the EAPI from the contents of the file doesn't require bash? 3) It uses the extension in a way that goes against common use in computers. What? It uses the extension to determine the format of the contents? -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Assuming that the file extension must change to prevent current PMs from trying to parse new format ebuilds (and not require waiting a year or more), I'd be a lot happier seeing it change *once* to a new fixed extension, with the requirement that the new ebuilds are required to contain within them them EAPI. This should future-proof the system. Preferably, shorten the extension and make a new standard. I noticed that .eb seems to be unused -- [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. ietf.org Are they ridiculous? lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Michael Haubenwallner wrote:
On Thu, 2007-12-20 at 17:22 +0100, Luca Barbato wrote:
I'm thinking about having them embedded in the comment as first line as
something like
#!/usr/bin/env emerge --eapi $foo
OT: It actually works adding this first line and do chmod +x foo.ebuild:
#! /usr/bin/env ebuild
Then you can do: ./foo.ebuild {digest,install,merge,whatever}
if we are lazy enough we could add this (and add --eapi foo support in
ebuild)
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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.. 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. Still I think we should just postpone this discussion and get a 2008.0 out. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 13:34:17 +0100 Piotr Jaroszyński [EMAIL PROTECTED] 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? Yes, for all intents and purposes, assume your readership is in elementary school. They're certainly not dump, maybe just ignorant, and whatever you're trying to achieve is coming their way, so you'd better have them on your side. Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 09:37:27 -0700 Joe Peterson [EMAIL PROTECTED] wrote: Assuming that the file extension must change to prevent current PMs from trying to parse new format ebuilds (and not require waiting a year or more), I'd be a lot happier seeing it change *once* to a new fixed extension, with the requirement that the new ebuilds are required to contain within them them EAPI. This should future-proof the system. Only until another source-level change comes along, which will hopefully be fairly soon -- eclasses need a good kick in the nuts, for example, and that pretty much means a source-level break. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
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... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 1:38 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: Here's some other ideas for how to express EAPI. What if we: [..] Stuck ranges into metadata.xml for which EAPIs applied? This is the easiest and most reasonable solution I've heard so far. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
2007/12/18, Joe Peterson [EMAIL PROTECTED]: Santiago M. Mola wrote: One example was mentioned in this thread before: You cannot use find -name '*.ebuild' anymore. So people could use a bit more elaborated expression to find them. Things like this shouldn't be a reason for not applying EAPI/GLEPs/PM-behaviour changes. If this GLEP is approved, it would be fine to publish a quick guide of recipes to migrate scripts which rely on the old naming convention and that should be enough. IMO, keeping us away from improvements to Gentoo because they break backwards compatibility with third party scripts is a no-go. Of course, this kind of changes can't happen once a month, but they can happen from time to time. I don't think this is about strictly maintaining backwards compatability. You are right that we should not let this impede progress. My objection is that the proposed scheme does not appear to make the system more elegant, but rather it creates complexity, potential errors (mismatches in representions of EAPI), and introduces a rather unorthodox and complicated file extension pattern. I also do not see why there are not other more elegant, transparent, and automatic ways to determine EAPI without sourcing. I put forth an idea, and I understand the objections to it, but I'm just brainstorming, and there *must* be other ways that retain portage's elegance and simplicity. -Joe -- [EMAIL PROTECTED] mailing list Just another brainstorming attempt. Is it possible to use one single file per eapi which lists all ebuilds using a specific eapi like package.eapi-name and is stored in the profiles. Or even one single file which lists the ebuild and its eapi. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Wed, 19 Dec 2007 16:38:01 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Here's some other ideas for how to express EAPI. What if we: Used EAPI-named subdirectories instead of tagging it into the filename? Performance hit, and otherwise equivalent to using suffixes. Used (and required) filesystem extended attributes? Unportable, unsyncable and unmaintainable. Stuck ranges into metadata.xml for which EAPIs applied? No package manager required information can be in XML format. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 08:29 Thu 20 Dec , Ciaran McCreesh wrote: On Wed, 19 Dec 2007 16:38:01 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Here's some other ideas for how to express EAPI. What if we: Used EAPI-named subdirectories instead of tagging it into the filename? Performance hit, and otherwise equivalent to using suffixes. Not quite so ugly-looking to my eyes. Used (and required) filesystem extended attributes? Unportable, unsyncable and unmaintainable. Unportable to filesystems that don't support extended attributes isn't very interesting to me, unless they're common. Out of curiosity, do you know which ones that would be? Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. Unsyncable would be a problem, so it's a good thing rsync has USE=xattr -- do the difficulties come in on the CVS side? Why do you say unmaintainable? Stuck ranges into metadata.xml for which EAPIs applied? No package manager required information can be in XML format. Says who? Us. We can change that, if we decide it's the best answer. =) Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz kirjoitti: On 08:29 Thu 20 Dec , Ciaran McCreesh wrote: On Wed, 19 Dec 2007 16:38:01 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Here's some other ideas for how to express EAPI. What if we: Used EAPI-named subdirectories instead of tagging it into the filename? Performance hit, and otherwise equivalent to using suffixes. Not quite so ugly-looking to my eyes. Used (and required) filesystem extended attributes? Unportable, unsyncable and unmaintainable. Unportable to filesystems that don't support extended attributes isn't very interesting to me, unless they're common. Out of curiosity, do you know which ones that would be? Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. Unsyncable would be a problem, so it's a good thing rsync has USE=xattr -- do the difficulties come in on the CVS side? Why do you say unmaintainable? Many users might have extended attributes support turned off in the kernel. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. Extended attributes can be turned off during compile time for each filesystem you mentioned. NFSv3 doesn't support them (yes, I do share $PORTDIR). Also note that in some circumstances like when running in a virtualized environment, imposing additional requirements on the kernel might be problematic. It wouldn't be great to require extended attributes for each and every Gentoo box... 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)
On Thu, 20 Dec 2007 01:19:46 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: On 08:29 Thu 20 Dec , Ciaran McCreesh wrote: On Wed, 19 Dec 2007 16:38:01 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: Here's some other ideas for how to express EAPI. What if we: Used EAPI-named subdirectories instead of tagging it into the filename? Performance hit, and otherwise equivalent to using suffixes. Not quite so ugly-looking to my eyes. It makes it quite a bit harder for developers to find the ebuild... Used (and required) filesystem extended attributes? Unportable, unsyncable and unmaintainable. Unportable to filesystems that don't support extended attributes isn't very interesting to me, unless they're common. Out of curiosity, do you know which ones that would be? Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. Unsyncable would be a problem, so it's a good thing rsync has USE=xattr That's an awful lot of requirements you're imposing upon people... do the difficulties come in on the CVS side? Version control systems don't tend to do anything beyond very basic permission related things... Getting the executable bit right is about the best you can hope for. Why do you say unmaintainable? Because they're almost entirely invisible. Stuck ranges into metadata.xml for which EAPIs applied? No package manager required information can be in XML format. Says who? Us. We can change that, if we decide it's the best answer. =) Say the Portage people for the past lots of years. (The reason, primarily, used to be that it used to be a dep upon a .so that could get broken. A better reason is that parsing XML is frickin' slow.) -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 10:43 Thu 20 Dec , Jan Kundrát wrote: Donnie Berkholz wrote: Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. Extended attributes can be turned off during compile time for each filesystem you mentioned. And? If you turn off features you need, things break. There's nothing new about that. If you disable ext3 support in your kernel, you can't mount an ext3 partition and you'll get an error during boot about not finding the root. NFSv3 doesn't support them (yes, I do share $PORTDIR). While doing a search about this, I came across a page on the Beagle site describing how Beagle deals with a similar issue that says: Extended attributes are used by Beagle to keep track of which files have been indexed and which need to be re-indexed. There is a sqlite-based fallback which is a bit slower, so it is recommended that you do use extended attributes. ... Your kernel will need support for extended attributes on the filesystem you are indexing. If you are using XFS or JFS, extended attributes are always enabled and you can skip this section and move on to Installing prerequisites. For Reiser3, ext2 and ext3 filesystems, the default kernel config does not enable the attributes. ... Also note that neither Reiser4 nor NFS support extended attributes, so the sqlite-based fallback will be used by default. The idea of the sqlite-based fallback is what's interesting here. Also note that in some circumstances like when running in a virtualized environment, imposing additional requirements on the kernel might be problematic. Why's that? Here's some performance tests from 3 years ago on a 2.6.10 kernel that hopefully have improved in the meanwhile: http://lwn.net/Articles/112566/ It wouldn't be great to require extended attributes for each and every Gentoo box... Why not? Thanks, Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote: Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. [...] The idea of the sqlite-based fallback is what's interesting here. I thought some of the other ideas were pretty bad... Guess I was wrong... This is the worst idea I have ever heard. -- Bo Andresen signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: If you turn off features you need, things break. There's nothing new about that. If you disable ext3 support in your kernel, you can't mount an ext3 partition and you'll get an error during boot about not finding the root. I see your point, but extended attributes aren't as common as ext3, are they. And stuff that got broken because Portage suddenly started to require new features on the kernel side is bad. The idea of the sqlite-based fallback is what's interesting here. If it is a fallback that must be supported (because of NFS), then there isn't much point in using xattrs. What benefits do they provide? There's no speed constraint here as we already cache metadata somewhere. Also note that in some circumstances like when running in a virtualized environment, imposing additional requirements on the kernel might be problematic. Why's that? Things with Xen got better than they were, but I can imagine a situation where some hosting provider offers their customers a virtual Xen box and their kernel configuration doesn't include extended attributes. You can't use your own kernel without access to dom0. It wouldn't be great to require extended attributes for each and every Gentoo box... Why not? Because they aren't so common, NFS doesn't support them and we haven't ever required them. Cheers, -jkt -- cd /local/pub more beer /dev/mouth signature.asc Description: OpenPGP digital signature
[gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Here's why I think you can't -- or at least shouldn't -- put EAPI into the filename. From your EAPI definition: 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. It's clearly NOT the purpose of a filename to describe how the contents of a file are structured/formatted/encoded/etc. It's sole purpose is to uniquely identify a file. Example: I use .txt to identify my text documents. However, I don't use .txt-utf-8, .txt-latin-1, .txt-iso-8859-15 just because their encoding differs. As cat/pkg-ver ultimately is ONE file in the filesystem, there's no reason to put any information about the EAPI in the filename. I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and the last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is bash syntax. If you just don't like EAPI being defined as variable (because future EAPIs could define that EAPI is assigned via a function), there are other ways to put this into the ebuild. Eg. Python PEP 0263 ([1]) proposes a way to declare the encoding inside of the source file. Same could be done for the EAPI. Or just write a GLEP that states EAPI has to be assigned via the EAPI variable. You're trying to *set* a standard here, so act accordingly. thomas [1] http://www.python.org/dev/peps/pep-0263/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 11:37:01 +0100 Thomas Pani [EMAIL PROTECTED] wrote: As cat/pkg-ver ultimately is ONE file in the filesystem, there's no reason to put any information about the EAPI in the filename. Sure there is. It's the sanest place to put it such that it's available when it's needed -- that is, before the ebuild is sourced. I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and the last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is bash syntax. Uh, I've explained it far too many times in this thread already. Go back and read. Don't post again until you understand it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Thu, 20 Dec 2007 11:37:01 +0100 Thomas Pani [EMAIL PROTECTED] wrote: As cat/pkg-ver ultimately is ONE file in the filesystem, there's no reason to put any information about the EAPI in the filename. Sure there is. It's the sanest place to put it such that it's available when it's needed -- that is, before the ebuild is sourced. I still don't get why EAPI=xxx is s bad. Obviously the GLEP (and the last 500 comments lack to explain that. Ebuilds are bash. EAPI=xxx is bash syntax. Uh, I've explained it far too many times in this thread already. Go back and read. Don't post again until you understand it. I DO understand. You say that explicitly having EAPI=xxx in the first non-comment line / in the ebuild header / whereever imposes restrictions on the ebuild format itself that go beyond it has to be bash. That's right. But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. There seem to be less people opposed to having that ebuild format restriction. So either choose the one that's accepted by the majority (and I'm not saying that EAPI=xxx is the one; I'm saying that we'll have to figure that out), or think of something completely new. Thomas Pani -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 12:06:59 +0100 Thomas Pani [EMAIL PROTECTED] wrote: But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. There seem to be less people opposed to having that ebuild format restriction. So either choose the one that's accepted by the majority (and I'm not saying that EAPI=xxx is the one; I'm saying that we'll have to figure that out), or think of something completely new. The ebuild format restriction does not solve the problem at hand. I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Extended attributes can be turned off during compile time for each filesystem you mentioned. If you turn off features you need, things break. There's nothing new about that. If you disable ext3 support in your kernel, you can't mount an ext3 partition and you'll get an error during boot about not finding the root. What you're proposing, though, is *requiring* a feature most people don't even know about or use. Yes, if I want to boot from ext3, I'll need support for it in the kernel. That's a very fundamental assumption and one that even our most challenged users will understand. Requiring extended attributes for the Portage tree is something completely different. There's simply no need to require additional features for something that can be done in the filename. Is there any *technical* reason you object to the GLEP? Because your aesthetic sense may be commendable but I for one find the suggestion *beautifully* simple. :-) Of course, taste can't be argued about (obviously I have an excellent taste and you don't! ;-) ) so I'd be really curious if there are technical reasons. It wouldn't be great to require extended attributes for each and every Gentoo box... Why not? Because we shouldn't require stuff we don't *have* to. -- Best regards, Wulf pgpuUbIFjtifc.pgp Description: PGP Digital Signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
I DO understand. You don't. The complete paragraph of yours shows you don't. But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. Yes, indeed. They're not happy with it. That's about all most participants here have stated so far. There are two or three valid *technical* concerns and all the rest is basically noise. There seem to be less people opposed to having that ebuild format restriction. If this was only about the ebuild format restriction, I wouldn't even bother to write a single mail on this subject. It's much more important than that - the suggested GLEP would allow us to make use of new EAPI features much earlier than now and without causing major problems, I think. Just this morning when I was reading my backlog in #-dev, I saw a discussion between between two devs that culminated in the following: a So we can make use of this feature in about a year? b Yeah. Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? So either choose the one that's accepted by the majority The majority of devs doesn't even read here (not to speak of active participation). -- Best regards, Wulf pgpZtv993UOWc.pgp Description: PGP Digital Signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 2007/12/20, Ciaran McCreesh [EMAIL PROTECTED] wrote: Uh, it works in both those cases. The package manager will simply not see the ebuild at all. Which is pretty much the point... Yes, because a change in the way EAPI is read implies a change in the files naming rule, so that the PM recognize the file only if it can do something useful with it. That's true for both proposals, which was pretty much my point. And that thus, it was not an argument in favor of one against the other. I still think that changing file names when absolutly required (switching from EAPI=foo to eapi foo, or moving it elsewhere, or switching to xml, etc.) is less disturbing than changing it for every single new EAPI. It's not because one new extension may not be eternally enough that we should introduce an infinity right now. But yeah, to be honest, you're right that my original as long as ebuilds stay bash was a bit optimistic: it was assuming there would be no decision of changing that rule as long as there would be no good reason for it (like a switch to xml or whatever other not-bash format). -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Donnie Berkholz wrote: Here's some other ideas for how to express EAPI. What if we: If this idea of eapi is the best. I'm doubtful it is. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 12:12 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... Stop guessing, then. You're way off. You apparently do not understand that an assertion without justification has no value in a serious discussion. Even it that has already been explained somewhere else, it may have been interpreted differently by different people (assuming they can find it). And sorry to disappoint you but you're not alway right. You have to give people a chance to contradict you, for your own good. Also, please stop thinking people have the exact same thing in mind as you because that leads to misunderstandings. All of us being different and thinking differently is why we are this good. There's nothing you can do about this, it's human nature. The day you'll understand all of this you'll be a much better dev and human being in general. And this day, working with you will be lots of fun. Too bad you were late when the specification for Man was written, because it seems we would have been much better than we are, and it would have been easier for you now. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Wulf C. Krueger wrote: a So we can make use of this feature in about a year? b Yeah. Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? What do we need so desperately? So either choose the one that's accepted by the majority The majority of devs doesn't even read here (not to speak of active participation). That says a lot in itself... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 2007-12-20 at 14:08 +0100, Thomas de Grenier de Latour wrote: snip Seems that there is a chain of different metadata levels: 1) The parser/interpreter/compiler/whatever to grok the ebuild. 2) *How* to extract the EAPI value from the ebuild(-filename), using 1) 3) The *value* of EAPI for that ebuild, using 2) 4) The contents of the ebuild, based on 3) To 1: for me it's absolutely acceptable to have it encoded in the filename (or extension). Fex we want to switch from bash to xml (for whatever reason), we could rename from *.ebuild to *.xbuild. But yeah, to be honest, you're right that my original as long as ebuilds stay bash was a bit optimistic: it was assuming there would be no decision of changing that rule as long as there would be no good reason for it (like a switch to xml or whatever other not-bash format). To 2: it might be acceptable to have it encoded into the filename. To 3 (and 2): Thomas++ I still think that changing file names when absolutly required (switching from EAPI=foo to eapi foo, or moving it elsewhere, or switching to xml, etc.) is less disturbing than changing it for every single new EAPI. It's not because one new extension may not be eternally enough that we should introduce an infinity right now. To 4: we agree that this never will be encoded in the filename ;) Just another bit of brainstorm (forget it if too broken): What if we do not start with EAPI=1 variable, but eapi 1 function immediately ? I could think of several implementations to let PM detect EAPI: *) Given it is the first bash-command in the ebuild: Just 'echo' the required EAPI and exit while PM is in look-for-eapi mode (remember 'eapi' function is part of PM, or profile.bashrc as fallback for ancient PM). *) As 'eapi' being a bash function, it could *migrate* the bash-environment from the PM's default EAPI to the given one - or just spit cannot migrate EAPI from A to B... *) Or just spit a message update your PM (from profile.bashrc) ... Just want to show that using 'eapi-function' should be more flexible than 'EAPI-variable', and thus will not be subject to change too often and require 2) (see above). /haubi/ -- Michael Haubenwallner Gentoo on a different level -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato a écrit : Wulf C. Krueger wrote: a So we can make use of this feature in about a year? b Yeah. Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? What do we need so desperately? So either choose the one that's accepted by the majority The majority of devs doesn't even read here (not to speak of active participation). That says a lot in itself... I'll speak up then :) What I _really_ would like to see ASAP : 1) Dropping digest-* files for real (ie, not even having them on the master rsync server and CVS) 2) Slotted deps (I had the feeling we were really close to having this a while back, and then radio silence, maybe I missed the final announcement?) 3) USE-deps As for the politics behind the naming of the EAPI, where it should be placed in the ebuild, whether it should be in metadata.xml or in the filename, I don't really care that much. I'm much more interested in the 3 points above. To all devs that will end up hacking on PMS and their respective PM : don't let yourselves drown into loong term plans. Let's be an opensource community with a release early, release often mentality. Happy Holidays :) Rémi -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Wulf C. Krueger wrote: I DO understand. You don't. The complete paragraph of yours shows you don't. Interesting, because my statement is the same (in meaning) that Ciaran made two days ago. He stated it was [...] another option. It's considered less ideal [...] ([1], in case you want to look it up) But you're totally ignoring my point. So once again: You're trying to *SET* a standard here. There are lots of people telling you that they're not happy with the proposal to change the ebuild filename suffix. Yes, indeed. They're not happy with it. That's about all most participants here have stated so far. There are two or three valid *technical* concerns and all the rest is basically noise. My concern is technical: Filenames are for identifying files uniquely. An ebuild is uniquely identified by cat/pn-pv, so that's what it's filename should be. Adding anything else to the filename will only clutter the tree and lead to additional inconsitencies. Yes, you can check for these using QA tools. But if it's not in the filename you don't have to check. If you say that package managers need the EAPI info so early that they can't even read the first non-comment line of an ebuild that's fine. Go and place it in the filename. But nobody had a *technical* argument why that's the only possible solution so far. All I got was you don't understand all that fancy PM stuff. There seem to be less people opposed to having that ebuild format restriction. If this was only about the ebuild format restriction, I wouldn't even bother to write a single mail on this subject. It's much more important than that - the suggested GLEP would allow us to make use of new EAPI features much earlier than now and without causing major problems, I think. Just this morning when I was reading my backlog in #-dev, I saw a discussion between between two devs that culminated in the following: a So we can make use of this feature in about a year? b Yeah. Are we Debian now? A new feature gets implemented (obviously because we *need* it) and we can make use of it in a *year*? No, we're not Debian, thank god. I thought the wait 1+ year policy changed? Again citing Ciaran: That was only the case because previously, using new features that Portage didn't support would cause horrible breakage. Now, instead, the ebuilds show up as being masked. [2] Regards, thomas [1] http://archives.gentoo.org/gentoo-dev/msg_149455.xml [2] http://archives.gentoo.org/gentoo-dev/msg_149031.xml -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Rémi Cardona wrote: I'll speak up then :) What I _really_ would like to see ASAP : 1) Dropping digest-* files for real (ie, not even having them on the master rsync server and CVS) 2) Slotted deps (I had the feeling we were really close to having this a while back, and then radio silence, maybe I missed the final announcement?) 3) USE-deps Ok those interesting. As for the politics behind the naming of the EAPI, where it should be placed in the ebuild, whether it should be in metadata.xml or in the filename, I don't really care that much. I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo or # EAPI=$foo IFF we want to consider single ebuilds, but since I don't like the approach at all here another proposal: I'd rather have a way to sync the tree so that: - if your pm supports all the features you get the tree - if your pm doesn't you get a minimal tree that let you update to the newer one. That means having a way to maintain a branch with just system and the update path and have a way to put eapi versioning per tree. This solves pretty much the root problems: do not have the package manager break on tree update and have a way to update the package manager from an ancient setup w/out unpacking a newer stage on it (that could be yet another solution) Feel free to flame/decostruct this proposal as you please. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Rémi Cardona wrote: I'll speak up then :) What I _really_ would like to see ASAP : 1) Dropping digest-* files for real (ie, not even having them on the master rsync server and CVS) Slated for after 2007.1 is released. 2) Slotted deps (I had the feeling we were really close to having this a while back, and then radio silence, maybe I missed the final announcement?) You can already. Assuming you don't mind putting EAPI=1 inside of your ebuilds. 3) USE-deps Ok those interesting. As for the politics behind the naming of the EAPI, where it should be placed in the ebuild, whether it should be in metadata.xml or in the filename, I don't really care that much. I'm thinking about having them embedded in the comment as first line as something like #!/usr/bin/env emerge --eapi $foo I always wondered why we didn't put a shebang as such at the top of ebuilds. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... So please make those people understand, so they can comment usefully. -- 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)
Jim Ramsay wrote: Luca Barbato [EMAIL PROTECTED] wrote: How would it be different than having EAPI=string put in a defined position of the file? It's not - It is just defining that position to be in the name of the file instead of the contents :) Exactly. And this way is not elegant. File name is used to uniquely identify a file in a system, not to decide how the content of the file should be interpreted. Never ever seen a file type extension with a version number. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. I think we also need to know: How many EAPI's do we have now? Where is the detailed definition of those EAPI's? How can we produce a new EAPI? IMO, we can not have more than two EAPI's simultaneously. The only situation in which we can have two EAPI is in the transition period of those two EAPI's. And we should set a time constraint on the transition. Other than that we can only have one working EAPI which all package managers conforms to. Otherwise, I think we may be risking forking the portage tree. -- 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)
Petteri Räty wrote: Donnie Berkholz kirjoitti: Unportable to filesystems that don't support extended attributes isn't very interesting to me, unless they're common. Out of curiosity, do you know which ones that would be? Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. Unsyncable would be a problem, so it's a good thing rsync has USE=xattr -- do the difficulties come in on the CVS side? Why do you say unmaintainable? Many users might have extended attributes support turned off in the kernel. /me raises hand. yup. don't use 'em. waste of kernel space. signature.asc Description: OpenPGP digital signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 8:01 PM, Zhang Le [EMAIL PROTECTED] wrote: How many EAPI's do we have now? In Portage tree we have 0 (default) and 1. There are others in external projects, for example prefix (in Gentoo/Alt:Prefix) or paludis-1 (used in paludis repositories). Where is the detailed definition of those EAPI's? 0, 1 and any further official EAPI are defined in PMS. There's a svn repository at http://svn.repogirl.net/pms How can we produce a new EAPI? I can't tell you the exact process, but look at EAPI bug trackers or search for bugs assigned to [EMAIL PROTECTED] Also, search in @-dev's archive. IMO, we can not have more than two EAPI's simultaneously. The only situation in which we can have two EAPI is in the transition period of those two EAPI's. And we should set a time constraint on the transition. Quite the opposite. EAPI's are designed to live happily together in the same repository. A current example: most (or lots...) ebuilds in the tree don't need EAPI=1 and it's pointless to migrate all of them. We can switch EAPI on an as needed basis. Other than that we can only have one working EAPI which all package managers conforms to. Read above, and other discussions. That's also pointless because we don't need to force all third party overlays to upgrade EAPI everytime we have a new one... -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On 11:26 Thu 20 Dec , Bo Ørsted Andresen wrote: On Thursday 20 December 2007 11:09:44 Donnie Berkholz wrote: Looking at my kernel config, ext3 and reiser explicitly support xattrs, and I see jfs and xfs have acls and security labels, which might be usable. [...] The idea of the sqlite-based fallback is what's interesting here. I thought some of the other ideas were pretty bad... Guess I was wrong... This is the worst idea I have ever heard. sarcasmThanks for your useful and detailed criticism./sarcasm Donnie -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Thomas Pani wrote: My concern is technical: Filenames are for identifying files uniquely. An ebuild is uniquely identified by cat/pn-pv, so that's what it's filename should be. Adding anything else to the filename will only clutter the tree and lead to additional inconsitencies. Yes, you can check for these using QA tools. But if it's not in the filename you don't have to check. If you say that package managers need the EAPI info so early that they can't even read the first non-comment line of an ebuild that's fine. Go and place it in the filename. But nobody had a *technical* argument why that's the only possible solution so far. All I got was you don't understand all that fancy PM stuff. Good point. First of all, and this is an architecture/design issue, the only valid reason to put the EAPI in the filename is that is *belongs* there in principal. File extensions are for file types, not for info that really should be in the file. If the motivation for placing the info in the filename (and worse, the *extension*) is that of performance, you should think twice about putting it there. If this is to address a technical problem, it should be solved in a technical way. The format of a filename should be determined by policy, not technical implementation or convenience. Technical reasons to avoid the filename are: 1) Increase of [needless] complexity in filenames/extensions (and only one example of the impact is that searching for ebuild files becomes less straightforward). 2) Having the same info in more than one place is bad (requiring extra repoman checks and the potential for ambiguity). I don't care how many people say a) that this is not an issue or b) that it's not a duplication, in every data system I've worked on, it has been a very bad idea to have more than one version of the same info that can get out of sync with each other. Even if you take great care, I'd still always want to check both and not trust either version of the info blindly. Caching or hashing is different (i.e. where the caching mechanism is robust), since the system itself keeps the cache up to date, and one version of the info is stricty derived from the other rather than both being the source. 3) It uses the extension in a way that goes against common use in computers. Other reasons: 1) Littering the filename with this kind of stuff is potentially confusing do both devs and users - I know it's been stated that users don't care, but I don't think that's a good assumption. 2) It does not appear to be an elegant filename policy (and this can be considered technical as well), since elegance is something designed int good systems. 3) Assuming going this route is a mistake, it could be hard to reverse. I just don't want to see something like this happen as a quick fix without exploring all of the implications and how it effects what I consider a very good system (portage/ebuilds) currently. Also, it seems to me that there are lots of other alternatives that have been discussed here (and some dismissed rather quickly). Portage and its policy are very core to Gentoo, and care should be taken on this. -Joe P.S. I just joined Gentoo this year, and it is disheartening to see the nastiness that some people are resorting to on this list. I've never seen so much anger and biting remarks in a project, and I can imagine it keeps some from responding, which is ashame, since issues like this benefit from many diverse viewpoints. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 16:57:54 +0100 Michael Haubenwallner [EMAIL PROTECTED] wrote: What if we do not start with EAPI=1 variable, but eapi 1 function immediately ? Uh. Then we're back to the zillion months wait before people can use anything. *) Given it is the first bash-command in the ebuild: Just 'echo' the required EAPI and exit while PM is in look-for-eapi mode (remember 'eapi' function is part of PM, or profile.bashrc as fallback for ancient PM). There isn't a look for eapi mode. *) As 'eapi' being a bash function, it could *migrate* the bash-environment from the PM's default EAPI to the given one - or just spit cannot migrate EAPI from A to B... Uh... No it couldn't. And there's no default EAPI. *) Or just spit a message update your PM (from profile.bashrc) ... Uh... No it couldn't. Please don't comment any further until you understand how this whole thing works. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 21 Dec 2007 02:52:16 +0800 Zhang Le [EMAIL PROTECTED] wrote: Exactly. And this way is not elegant. File name is used to uniquely identify a file in a system, not to decide how the content of the file should be interpreted. Never ever seen a file type extension with a version number. http://httpd.apache.org/docs/2.0/mod/mod_mime.html You might find that interesting reading. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 14:33:25 -0700 Joe Peterson [EMAIL PROTECTED] wrote: P.S. I just joined Gentoo this year, and it is disheartening to see the nastiness that some people are resorting to on this list. I've never seen so much anger and biting remarks in a project, and I can imagine it keeps some from responding, which is ashame, since issues like this benefit from many diverse viewpoints. No. Issues like this benefit from *well informed* diverse viewpoints. They don't benefit from people running around going waah! waah! doesn't look nice! add format restrictions! without understanding why it's necessary. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Thu, 20 Dec 2007 14:54:10 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: On Dec 20, 2007 12:12 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... Stop guessing, then. You're way off. You apparently do not understand that an assertion without justification has no value in a serious discussion. I was being nice. Next time I'll post a list of names of people who don't understand the metadata generation process and who therefore can't comment usefully... Even it that has already been explained somewhere else, it may have been interpreted differently by different people (assuming they can find it). How they interpret is different from the objective fact of what the process is. And sorry to disappoint you but you're not alway right. You have to give people a chance to contradict you, for your own good. People who know what they're talking about are more than welcome to contradict me. People who don't understand what's being discussed (which is most people in this thread) need to learn to stop wasting people's time. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: No. Issues like this benefit from *well informed* diverse viewpoints. They don't benefit from people running around going waah! waah! doesn't look nice! add format restrictions! without understanding why it's necessary. Putting a tag in the file name or at the to of the file as comment (maybe using a #! line) is the same ... We aren't on DOS we can use that nice tool called file and it's magic... lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- [EMAIL PROTECTED] mailing list
