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: [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: [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.
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
