[gentoo-dev] Re: GLEP 55 updated
Joe Peterson wrote: Ciaran McCreesh wrote: 3. Extend versioning rules in an EAPI - for example, addition of the scm suffix - GLEP54 [1] or allowing more sensible version formats like 1-rc1, 1-alpha etc. to match upstream more closely. Apart from GLEP54, I believe our versioning scheme works reasonably well. I don't see any need to match upstream more closely. I'd rather like to keep the more uniform way of handling suffixes like rc and alpha, that we have now. Please explain why 1.2_rc3 is legal but 1.2-rc3 is not. I actually like the current format in that it does *not* allow - in the version. For example, pkg-2.3.1_rc5 makes it clear that the string from 2 to rc5 is the version. If were were to allow pkg-2.3.1-rc5, this could get visually confusing (looks a bit like pkg-2.3.1-r5). In this case, *less* flexibility and more strict rules serve a good purpose, I think. Agreed; the purpose of an internal format specification is not to allow NN variants on a theme all over the place. It should nail things down to ONE variant which everybody can collaborate around. I missed the clamour of developers complaining about this oh-so-burdensome restriction that they've been dealing with for at least 5 years. Until I see that happening independently of this current hooha, I'm going to consider this 'reason' to be yaf straw man. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 16:07:20 +0100 Steven J Long sl...@rathaus.eclipse.co.uk wrote: I missed the clamour of developers complaining about this oh-so-burdensome restriction that they've been dealing with for at least 5 years. Why do you think I wrote the awful hack that is versionator? Anything that finally lets us kill that off has to be good... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. Anything that finally lets us kill that off has to be good... Loosening VERSION requirements won't fix the problem. This will: 1) Discourage its use by putting a QA ewarn in the eclass. 2) Have all ebuilds converted either through QA bugs or a nice Saturday afternoon coding spree. 3) Announce its removal. 4) Remove.
[gentoo-dev] Re: GLEP 55 updated
David Leverton wrote: 2009/5/17 Ben de Groot yng...@gentoo.org: I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure. Ugh. Firstly versionator is a piece of bloated crap that should have died a long time ago; all it does is stop Gentoo newbs learning the basics[1] of their implementation language, which leaves them open to nonsensical arguments about printf -v (glad you finally learnt that one, btw.) Secondly, please explain fully and clearly, but concisely, why we can't simply state that EAPI=NN allows the ebuild to use the EAPI functions in global scope. Bear in mind that you have to deal with the case of the mangler which can get EAPI from an ebuild without sourcing, as portage currently can, I believe. Relaxing that restriction strikes me as much saner than relaxing all the other restrictions which make interoperability easier. (Frankly, I'm amazed at having to state that to people trusted to write a specification. Follow up to -project on this point please, as it's about process, not technique.) [1] (watch wrap) http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02 http://wooledge.org/mywiki/BashFAQ/073 man bash /Parameter Expansion -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: GLEP 55 updated
Ciaran McCreesh wrote: On Mon, 18 May 2009 16:07:20 +0100 Steven J Long sl...@rathaus.eclipse.co.uk wrote: I missed the clamour of developers complaining about this oh-so-burdensome restriction that they've been dealing with for at least 5 years. Why do you think I wrote the awful hack that is versionator? Anything that finally lets us kill that off has to be good... I have to disagree. As Steve said, the fact that Gentoo has a strict way to specify versions brings clarity and uniformity to our tree, regardless of the myriad upstream conventions. I do not think that allowing all of those upstream conventions in our filenames is a benefit. It is actually quite ugly and would make the tree harder to comprehend. Someone looking at various packages in our tree would need to learn each specific upstream format in order to make sense of the filename content. The current consistency in versions in the tree is a great feature, IMHO. Using versionator and $MY_PV is, as I see it, a translation method. It gives us the best of both worlds: the ability to deal with upstream versions and a consistent Gentoo version format. These mechanisms could certainly be improved upon, of course, and handling some cases is currently difficult, as is handing the case in which upstream's tarball file does not contain the version, but these are fixable issues. -Joe
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 17:28:00 +0200 Jeroen Roovers j...@gentoo.org wrote: On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. Versionator was created because the alternative was worse: developers were hard-coding versions in ebuilds, writing dodgy bash substitutions that wouldn't reliably convert between versions and using things like sed and tr in global scope. The problem is, versionator was written before the current version rules. It doesn't handle some things that are now legal, and it still uses the old meanings for numeric components. The correct solution is two-fold: * Replace versionator with package-manager internal functions that use the package manager's rules for version parsing. * Reduce the need to use MY_PV by extending the version rules. Both of these are things that can't be done with current EAPI rules. Anything that finally lets us kill that off has to be good... Loosening VERSION requirements won't fix the problem. This will: 1) Discourage its use by putting a QA ewarn in the eclass. 2) Have all ebuilds converted either through QA bugs or a nice Saturday afternoon coding spree. 3) Announce its removal. 4) Remove. You can't discourage versionator until the replacement's in place. Going back to the old way of doing things is a loot worse than using versionator. So no, the way to fix it is: 1) Change the EAPI rules to allow global scope and version suffix changes. 2) Bring in a versionator replacement done as internals in a new EAPI. 3) Extend the version format rules in a new EAPI. 4) Disallow versionator use in the first EAPI that has 2) and 3). -- Ciaran McCreesh signature.asc Description: PGP signature
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Monday 18 May 2009, Jeroen Roovers wrote: On Mon, 18 May 2009 16:16:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Why do you think I wrote the awful hack that is versionator? Why don't you explain why, historically, you put that in the tree? It would help us now if you were to simply record your mistakes for everybody else to easily avoid. It's still being used in the tree and should be discouraged. I'm not following. Why should it be discouraged? I was happy with it until now. Robert signature.asc Description: This is a digitally signed message part.
Re: versionator.eclass terminator, was [gentoo-dev] Re: GLEP 55 updated
On Mon, 18 May 2009 17:42:19 +0200 Robert Buchholz r...@gentoo.org wrote: I'm not following. Why should it be discouraged? I was happy with it until now. Versionator is a lot better than what people were doing before I wrote it. It's just nowhere near as good as what a package manager provided solution combined with a reduced need for MY_PV hacks would give. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55 updated
2009/5/18 Steven J Long sl...@rathaus.eclipse.co.uk: David Leverton wrote: 2009/5/17 Ben de Groot yng...@gentoo.org: I think the way eapi-2 was introduced into the tree wasn't particularly problematic. I think there might be a misunderstanding here. Ciaran means functions provided by the package manager that ebuilds can call during metadata generation, for example built-in versionator-like functionality, not new phase functions like src_prepare and src_configure. Ugh. Firstly versionator is a piece of bloated crap that should have died a long time ago; all it does is stop Gentoo newbs learning the basics[1] of their implementation language, which leaves them open to nonsensical arguments about printf -v (glad you finally learnt that one, btw.) Yes, it should have died a long time ago, that's why we're talking about adding equivalent built-in functionality. Please try to keep up. (And it's always amusing to see your bizarre delusions about what I do and don't know.) Secondly, please explain fully and clearly, but concisely, why we can't simply state that EAPI=NN allows the ebuild to use the EAPI functions in global scope. Because by the time the package manager knows the EAPI and is in a position to provide the appropriate functions, the ebuild will have already tried to use them. Bear in mind that you have to deal with the case of the mangler which can get EAPI from an ebuild without sourcing, as portage currently can, I believe. Interesting Relaxing that restriction strikes me as much saner than relaxing all the other restrictions which make interoperability easier. (Frankly, I'm amazed at having to state that to people trusted to write a specification. Follow up to -project on this point please, as it's about process, not technique.) You're amazed that people trusted to write a specification don't already know what strikes you as much saner? Believe it or not, the world does not revolve around you and your opinions.
[gentoo-dev] Re: GLEP 55 updated
On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: GLEP 55 updated
2009/5/17 Ryan Hill dirtye...@gentoo.org: On Sun, 17 May 2009 17:56:06 +0200 Piotr Jaroszyński pe...@gentoo.org wrote: Hello, I have just updated GLEP 55 [1], hopefully making it a bit clearer. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change I can live with any of these if that's what it takes to move forward. I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. That's covered in the GLEP: Note that it is still not permitted to have more than one ebuild with equal category, package name, and version. Although it would have the advantage of allowing authors to provide backwards compatible ebuilds, it would introduce problems too. The first is the requirement to have strict EAPI ordering, the second is ensuring that all the ebuilds for a single category/package-version are equivalent, i.e. installing any of them has exactly the same effect on a given system. I don't see a way to overcome these problems in a sensible way. -- Best Regards, Piotr Jaroszyński
Re: [gentoo-dev] Re: GLEP 55 updated
On Sun, 17 May 2009 12:15:24 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. We couldn't. Allowing multiple equal but different ebuilds gets highly crazy -- EAPIs aren't orderable, so it's not obvious which one the package manager should select. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 55 updated
On Sun, 17 May 2009 19:18:14 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sun, 17 May 2009 12:15:24 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'd like 2 if we could have multiple same-versioned ebuilds of different EAPI. 3 is good enough for me. We couldn't. Allowing multiple equal but different ebuilds gets highly crazy -- EAPIs aren't orderable, so it's not obvious which one the package manager should select. Ah, right. I knew there was a reason. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: GLEP 55 updated
Just a heads up that I wrote a more detailed description of the peformance hit that EAPI in the ebuild introduces. Might come up with some numbers later too. [1] - http://dev.gentoo.org/~peper/glep-0055.html#easily-fetchable-eapi-inside-the-ebuild -- Best Regards, Piotr Jaroszyński
