[gentoo-dev] Re: Re: GLEP 55 Version 2
Roy Bamford wrote: On 2009.06.07 10:34, Ulrich Mueller wrote: On Sun, 07 Jun 2009, Steven J Long wrote: I'd just like to know what the implications would be for users if we kept the .ebuild extension, and a new PMS were rolled out stating that the mangler were allowed to find the EAPI without sourcing (and giving the restrictions) once portage 2.2 was stable, or the ability to handle this backported to 2.1.6, and issued in a release? Even if we do only a one-time change of the file extension, can we ever get rid of the old extension? Or are we then stuck with two extensions in the tree until the end of time? Let's assume for the moment that we change from .ebuild to .eb. Then we obviously cannot change all ebuilds in the tree to .eb, otherwise old Portage versions would see an empty tree and there would be no upgrade path. Or am I missing something? Sounds about right First, lets be clear that the upgrade path related problems are driven by the EAPI change, not the .ebuild to .eb change. That serves only to allow the new EAPI to be introduced immedately and hide the change from older package managers snip To keep an upgrade path, package managers and their dependencies need to use EAPI 0, 1 or 2. (EAPI 3 is not yet out) How far back should the upgrade path extend? Well given that EAPI 3 is not out, and that bash-4 is not even stable (and if anyone thinks we can rely on bash-4 in the next 6 months, they didn't learn anything from bash-3 imo) this sounds like it's a fair distance away. From discussion with Harring, EAPIs were not meant to come out very often; iirc he said something like maybe once a year. I concur with Duncan on a year, as you know. I appreciate you feel it should be longer, and am happy to go with whatever the consensus is. As you suggest, even with .ebuild to .eb change.its not a clean break with the past but would happen over time, with ebuilds for new package versions being migrated to the new format. For example we would have foo-2.1-r1.ebuild foo-3.0.eb portage-2.3.ebuild portage-3.0.eb yuck. Portage-2.3 will understand the later EAPI but will itself, use only EAPI, 0, 1 or 2. Just to be clear: portage-2.2 and later will be fine with any EAPI, with no change to any ebuilds, nor any new extension being needed. The change can easily be backported to 2.1.6, tho I suspect 2.2 will be stable fairly soon. Thats just portage. The same reasoning applies to any other package manager and there are at least three. This begs the question of how friendly do we want to be to derivitive distros that use our tree but their own package manager? As friendly as we can be without hobbling our own development. Most of them appear to be fairly collaborative with Gentoo in any case. Upgrade path issues need to be addressed in the GLEP. I will add something like the above in the next version. Wrt transitioning, can the eapi (PMS 5.2.2) and deprecated (5.2.3) files not be of use? I seem to recall the change from 2007.1 to 2008.0 for example; anyone using a deprecated profile can expect a massive warning the next time they try to do anything after sync'ing. Thanks again for your work; I appreciate that your time is valuable. Regards, Steve. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
[gentoo-dev] Re: Re: GLEP 55
Luca Barbato wrote:
Tiziano Müller wrote:
Joe Peterson wrote:
Ciaran McCreesh wrote:
And a file extension is far less obscurely complex than enforcing
arbitrary syntax restrictions upon ebuilds.
I disagree. One is exposed to devs only as ebuild syntax; the other is
exposed in an inappropriate location to everyone looking at the portage
tree.
No it can't. EAPI has to be known before the source can start. Bash
doesn't provide traps for executing code upon changed variables.
Doing it out-of-band solve this.
No, it's only needed once per non-trivial change. So we might as well
just change it for every EAPI.
Huh? If the new portage knows how to determine the EAPI definitively
(and that would be defined), it can deal with the differences.
And then how do we deal with EAPI 3, where the syntax changes again?
Portage (or whatever PM) reads the EAPI, determines it is 3, and goes
from there. If you change the way you declare EAPI each time, yeah,
that's a problem, but I'm not sure why that would ne necessary.
No, that is not the problem.
Example:
In EAPI 42 we define that the package manager must provide a global
function extract_depend_from_setup_py() such that it is callable at a
global level in an ebuild like this
*snip start*
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=42
DESCRIPTION=A library aiming to support agile and test-driven python
development on various levels.
SRC_URI=http://codespeak.net/download/${PN}/${P}.tar.gz;
HOMEPAGE=http://codespeak.net/py/;
KEYWORDS=~amd64 ~x86
SLOT=0
LICENSE=MIT
IUSE=
extract_depend_from_setup_py
*snip end*
Now, a package manager (or a tool) not knowing EAPI 42 will fail when it
tries to source the above ebuild to determine the EAPI version (as it is
being currently done as far as I understood it) because
extract_depend_from_setup_py is undefined.
So it won't even be able to read out the EAPI.
With the EAPI in the filename tools now knowing EAPI-42 will either
ignore the above foo-1.0.ebuild-42 or mask it because they may identify
the EAPI-version without sourcing the ebuild.
Check if exists a line EAPI=*$, if does and the rest of the string
matches an understood eapi, go on sourcing, otherwise ignore/mask it...
... and package managers which don't do that already still fail.
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. -- Best Regards, Piotr Jaroszyński ���^�X��� ��(��j)b�b�
Re: [gentoo-dev] Re: Re: GLEP 55
Tiziano Müller wrote: ... and package managers which don't do that already still fail. To put everything in perspective all this discussion is done in order to workaround the issue of an old and outdated package manager that cannot be upgraded once it syncs from a too new repository. The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
On Tue, 10 Jun 2008 12:22:03 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Tiziano Müller wrote: ... and package managers which don't do that already still fail. To put everything in perspective all this discussion is done in order to workaround the issue of an old and outdated package manager that cannot be upgraded once it syncs from a too new repository. The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So you're volunteering to convert the entire tree to the new EAPI all in one go every two months? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 55
Piotr Jaroszyński wrote: The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. It isn't you just keep 2 repos, one with the minimal eapi and the minimal set of ebuilds needed to upgrade, one with the latest and greatest. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
On Tue, 10 Jun 2008 13:13:34 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: So you're volunteering to convert the entire tree to the new EAPI all in one go every two months? I don't see the need and I won't see the problem given right now what is interesting is the set of improvements that aren't forward incompatible. It's likely that any future EAPIs won't be forward compatible because: * There's a strong desire to make lots of functions stricter. * The current *DEPEND syntax will probably be replaced with something more expressive. * There'll be more phases. So yes, it's a full tree rewrite if you want to avoid having multiple EAPIs in the same tree. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 55
On 10 Jun 2008, at 13:13, Luca Barbato wrote: but I dislike empty theories or hardly searched corner cases that could be avoided with half of the effort necessary to get there. Yoy mean like adopting GLEP55, right? - ferdy -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Ciaran McCreesh wrote: So you're volunteering to convert the entire tree to the new EAPI all in one go every two months? I don't see the need and I won't see the problem given right now what is interesting is the set of improvements that aren't forward incompatible. Being that the case you'd just need 2 trees, managed as overlay and a marker for each tree on which eapi to use, but I dislike empty theories or hardly searched corner cases that could be avoided with half of the effort necessary to get there. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Luca Barbato schrieb: Piotr Jaroszyński wrote: The simplest way is to change the syncpoint in the new package manager and leave the previous uri with a compatibility repo for the older ones. So we add a new repo each time a new EAPI comes out? Sounds like a big mess. It isn't you just keep 2 repos, one with the minimal eapi and the minimal set of ebuilds needed to upgrade, one with the latest and greatest. lu Then you could also just provide binaries... But lets face it, it slows down progress, because you will delay every change, because stuff like that you will only do if necessary. And it is still huge pain, from a users point of view, to upgrade stuff. And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. I still haven't seen any good reasons against it. And btw, the KDE overlay users don't seem at all to be confused, because the packages are named .kdebuild-1 instead of .ebuild. Portage (and other tools) keeps happily ignoring them, like it should. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
Bernd Steinhauser wrote: And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. In any design, there are easy short-cuts that can be taken. But sometimes these short-cuts break paradigms that are fundamental. If you wanted, you could throw a bunch of things into the filename and make it 255 characters long to avoid reading the file, but that clearly would be a pretty bad design. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. Is the huge mess you are thinking of the basic reality that software of any reasonable complexity needs to deal with file formats evolving? If so, that is exactly why EAPIs now are being introduced. But almost all software deals with this transparently - no need to expose it to the user, and sticking the version in the filename is both fragile (renaming the file can alter it) and seems like a hack. I still haven't seen any good reasons against it. I realize that there are two camps of people here. One camp sees mangling the filename extension as an undesirable way to deal with this, and the other camp simply sees no problem with this. I want to point out, however, that the fact that you do not see the issue does not make the issue invalid. I am sure there are people who work at Apple who care nothing about the way an iPhone looks or feels and only care that it works correctly. If that person went to Steve Jobs and said, Why are you spending so much money to make this thing look cool?, he would say that Apple is known for making cool things, and no one would buy something that works great but looks like a piece of junk. He'd be right. I realize this analogy is a bit of an exaggeration, but there is no reason we cannot make EAPIs work correctly and very efficiently (this is where technical innovation comes in), while also keeping the basic interface (and I include file name convention here) clean, standard, uncluttered, uncomplicated, and elegant. -Joe -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 55
On Tue, 10 Jun 2008 09:02:29 -0600 Joe Peterson [EMAIL PROTECTED] wrote: But almost all software deals with this transparently - no need to expose it to the user, and sticking the version in the filename is both fragile (renaming the file can alter it) and seems like a hack. The typical user does not deal with the ebuild files themselves, and if they are doing so it's because there's a deficiency in the tools available to them. Any user who *does* deal with ebuild files is doing something sufficiently advanced that they need to be aware of EAPIs anyway. As for fragile... You might as well say that sticking PN and PV in the file is fragile and a hack... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: GLEP 55
Joe Peterson schrieb: Bernd Steinhauser wrote: And that is, what this is about, making EAPI bumps as less painful as possible. The filename is the easiest solution for that. In any design, there are easy short-cuts that can be taken. But sometimes these short-cuts break paradigms that are fundamental. If you wanted, you could throw a bunch of things into the filename and make it 255 characters long to avoid reading the file, but that clearly would be a pretty bad design. Yes, in principle you could do that, but in principle you could do the same with the first line in a file or whatever you are suggesting. I really fail to see the point, why it is so important, that the extension will still be .ebuild in the future. There is a lot of software, that keeps using the same filename for different versions of stuff and in many cases, that is a huge mess. Is the huge mess you are thinking of the basic reality that software of any reasonable complexity needs to deal with file formats evolving? If so, that is exactly why EAPIs now are being introduced. But almost all software deals with this transparently - no need to expose it to the user, and sticking the version in the filename is both fragile (renaming the file can alter it) and seems like a hack. Wow, altering the content of a file can alter it, too. What is the point there? BTW, so you are suggesting, that we shouldn't put the PV in the file name? We shouldn't put the revision in the file name? Hm, so in the future, there will be a metadata.xml file, that defines: - EAPI - PV - KEYWORDS - more stuff of the ebuild? Sounds complicated. I still haven't seen any good reasons against it. I realize that there are two camps of people here. One camp sees mangling the filename extension as an undesirable way to deal with this, and the other camp simply sees no problem with this. Seems to be like that. But I am really impress, how far some people go, to avoid renaming the file extension of a file. -- gentoo-dev@lists.gentoo.org mailing list
