| 1 |
On Fri, 2006-06-02 at 19:48 +0200, Paul de Vrieze wrote: |
| 2 |
> On Friday 02 June 2006 18:47, Marius Mauch wrote: |
| 3 |
> > Actually this is probably the main problem of all the "package manager |
| 4 |
> > compability" gleps: We don't have a proper specification, all existing |
| 5 |
> > docs more or less are based on the existing portage implementation. So |
| 6 |
> > right now the implementation is the authorative specification, which of |
| 7 |
> > course creates some problems. |
| 8 |
> > IMO before any such glep can be considered we need a proper |
| 9 |
> > specification about our package and repository formats, otherwise you |
| 10 |
> > can't really validate any package manager (the statespace is a bit |
| 11 |
> > large for equivalence checks). |
| 12 |
> |
| 13 |
> The problem is actually that such a document is a living thing and it must not |
| 14 |
> only exist initially but be maintained continuously. |
| 15 |
|
| 16 |
Yes and no. EAPI=0 is somewhat nailed down. We could nail it down |
| 17 |
further. Any future EAPI versions could easily be written as just the |
| 18 |
differences from the previous EAPI. |
| 19 |
|
| 20 |
fex. EAPI=1 (or whatever) could be something like: all of EAPI=0 + |
| 21 |
multiple repositories (and a definition of requirements), USE-based |
| 22 |
dependencies (and a definition of requirements/etc), and per-package |
| 23 |
use.mask (including all the necessary information. |
| 24 |
|
| 25 |
Honestly, it is really bad that we do *not* have a listing of what is |
| 26 |
and what is not allowed in ebuilds. We have lots of different places |
| 27 |
where such things exist, but no one clear definition. We really need a |
| 28 |
single, concise definition of what exactly *is* an ebuild before trying |
| 29 |
to proceed further. |
| 30 |
|
| 31 |
Things to consider: |
| 32 |
|
| 33 |
- required variables (SRC_URI, DESCRIPTION, HOMEPAGE) |
| 34 |
- disallowed variables (P, T, PN) |
| 35 |
- valid non-function abilities (inherit is all that comes to mind) |
| 36 |
- description of default functions (as in what they are, not so much |
| 37 |
what they do in detail) |
| 38 |
|
| 39 |
I'm sure there's *tons* and *tons* more stuff, but this is a start. We |
| 40 |
do have quite a bit of this in the ebuild man page, os it isn't like |
| 41 |
we'd have to start from scratch. |
| 42 |
|
| 43 |
-- |
| 44 |
Chris Gianelloni |
| 45 |
Release Engineering - Strategic Lead |
| 46 |
x86 Architecture Team |
| 47 |
Games - Developer |
| 48 |
Gentoo Linux |
Archives