[gentoo-dev] Glep 49 (g2boojum's version)
Grant, Apologies; I can't find your note from yesterday, so I can't respond to the correct topic. One question just occurred to me; if it's been addressed before, apologies about that, too. Your requirement that any alternative package manager support any ebuild which portage supports seems essential, except for a boundary case. What about ebuilds which for whatever reason are invalid (serious specification violation, for example, to the extent that QA would reject them), but portage accepts them anyway. Must the alternative accept them as well? In a case like this, it seems to me that the ebuild works because of a bug in portage, and there should be no complaint if as a side effect of fixing this bug the ebuild in question quit working. If memory serves me, things like this have indeed happened. I can't recall a specific, however. Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick [EMAIL PROTECTED] wrote: What about ebuilds which for whatever reason are invalid (serious specification violation, for example, to the extent that QA would reject them), but portage accepts them anyway. Must the alternative accept them as well? Precedent says that a new (minor) Portage version can quite happily break such ebuilds, so I see no reason to say that any alternative should accept them. On a side note, this is part of the reason why we really need the ebuild/tree format properly defined somewhere. It would remove any worries about compatibility between ebuilds and package managers, as long as ebuilds conform to a given specification, and the package manager supports it. It also defines in a much better manner just what a broken ebuild is. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 02 Jun 2006 16:17:06 + Ferris McCormick [EMAIL PROTECTED] wrote: Grant, Apologies; I can't find your note from yesterday, so I can't respond to the correct topic. One question just occurred to me; if it's been addressed before, apologies about that, too. Your requirement that any alternative package manager support any ebuild which portage supports seems essential, except for a boundary case. What about ebuilds which for whatever reason are invalid (serious specification violation, for example, to the extent that QA would reject them), but portage accepts them anyway. Must the alternative accept them as well? In a case like this, it seems to me that the ebuild works because of a bug in portage, and there should be no complaint if as a side effect of fixing this bug the ebuild in question quit working. If memory serves me, things like this have indeed happened. I can't recall a specific, however. Actually this is probably the main problem of all the package manager compability gleps: We don't have a proper specification, all existing docs more or less are based on the existing portage implementation. So right now the implementation is the authorative specification, which of course creates some problems. IMO before any such glep can be considered we need a proper specification about our package and repository formats, otherwise you can't really validate any package manager (the statespace is a bit large for equivalence checks). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Friday 02 June 2006 18:47, Marius Mauch wrote: Actually this is probably the main problem of all the package manager compability gleps: We don't have a proper specification, all existing docs more or less are based on the existing portage implementation. So right now the implementation is the authorative specification, which of course creates some problems. IMO before any such glep can be considered we need a proper specification about our package and repository formats, otherwise you can't really validate any package manager (the statespace is a bit large for equivalence checks). The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsnabAA0l7F.pgp Description: PGP signature
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to change, a new specification should be created based on the current one, and EAPI bumped. Each individual document should remain more or less unchanged once it's finalised, barring minor bugfixes. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
Stephen Bennett wrote: On Fri, 2 Jun 2006 19:48:39 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Must it? I'd be more inclined to say that if it needs to change, a new specification should be created based on the current one, and EAPI bumped. Each individual document should remain more or less unchanged once it's finalised, barring minor bugfixes. I think this is what he means by maintained...aka someone needs to either update the spec, or create a new one. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Glep 49 (g2boojum's version)
On Fri, 2006-06-02 at 19:48 +0200, Paul de Vrieze wrote: On Friday 02 June 2006 18:47, Marius Mauch wrote: Actually this is probably the main problem of all the package manager compability gleps: We don't have a proper specification, all existing docs more or less are based on the existing portage implementation. So right now the implementation is the authorative specification, which of course creates some problems. IMO before any such glep can be considered we need a proper specification about our package and repository formats, otherwise you can't really validate any package manager (the statespace is a bit large for equivalence checks). The problem is actually that such a document is a living thing and it must not only exist initially but be maintained continuously. Yes and no. EAPI=0 is somewhat nailed down. We could nail it down further. Any future EAPI versions could easily be written as just the differences from the previous EAPI. fex. EAPI=1 (or whatever) could be something like: all of EAPI=0 + multiple repositories (and a definition of requirements), USE-based dependencies (and a definition of requirements/etc), and per-package use.mask (including all the necessary information. Honestly, it is really bad that we do *not* have a listing of what is and what is not allowed in ebuilds. We have lots of different places where such things exist, but no one clear definition. We really need a single, concise definition of what exactly *is* an ebuild before trying to proceed further. Things to consider: - required variables (SRC_URI, DESCRIPTION, HOMEPAGE) - disallowed variables (P, T, PN) - valid non-function abilities (inherit is all that comes to mind) - description of default functions (as in what they are, not so much what they do in detail) I'm sure there's *tons* and *tons* more stuff, but this is a start. We do have quite a bit of this in the ebuild man page, os it isn't like we'd have to start from scratch. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
