1 |
On Wednesday 17 May 2006 18:05, Ciaran McCreesh wrote: |
2 |
> On Wed, 17 May 2006 17:48:32 +0200 Paul de Vrieze <pauldv@g.o> |
3 |
> |
4 |
> wrote: |
5 |
> | This is basically to protect the official package manager. This is |
6 |
> | not because I like portage that much, but to provide some kind of |
7 |
> | unified direction. I am afraid that allowing various competing |
8 |
> | package managers would cause a wildfire of incompatible elements in |
9 |
> | the tree. Therefore there must be one official package manager that |
10 |
> | the tree works with. |
11 |
> |
12 |
> You're saying "we must never move forward" here. There is no |
13 |
> requirement that users use packages that are EAPI masked, any more than |
14 |
> there is a requirement that users use packages that are package masked. |
15 |
> We have had situations in the past where some ebuilds have relied upon a |
16 |
> non-stable or hard-masked Portage version. |
17 |
|
18 |
Currently we do not have any separation between core and non-core packages, |
19 |
but what would you say about this being the case for expat, and what about |
20 |
glibc? Every package that is not available to the official package manager |
21 |
hampers its credibility as the official package manager. In the case of a |
22 |
non-stable or hard-masked portage, this fact by itself limits the application |
23 |
of such packages. In case of an alternative package manager it is a lot |
24 |
easier to say "just install pkgcore (other contentor, to not mention paludis |
25 |
all the time), and it works". At that point this package manager takes over |
26 |
the role of primary package manager by the back door. |
27 |
|
28 |
What I say is that we can move forward, but in conscious steps. There are many |
29 |
things that can be done without introducing packages to the tree that do not |
30 |
work with a current or planned version of the official package manager. |
31 |
|
32 |
Please know that I don't mind portage being replaced. I don't think any of its |
33 |
developers are particularly in love with its spaghetti code. I do however |
34 |
think that a conscious decision should be made on whether and which package |
35 |
manager replaces portage. |
36 |
|
37 |
> | > The same situation will occur when newer Portage versions supporting |
38 |
> | > newer EAPIs are released into p.mask or ~arch. Some packages will |
39 |
> | > end up relying upon something that isn't the stable package manager. |
40 |
> | |
41 |
> | Portage is however the official package manager. This means that |
42 |
> | these packages do not hamper the position of the official package |
43 |
> | manager. |
44 |
> |
45 |
> The "official package manager" isn't something that's in package.mask. |
46 |
|
47 |
It is however certain that portage will be replaced at some point by a new |
48 |
portage that is either the package masked version, or that the package masked |
49 |
version is obsoleted. |
50 |
|
51 |
Paul |
52 |
|
53 |
-- |
54 |
Paul de Vrieze |
55 |
Researcher |
56 |
Mail: pauldv@×××××.nl |
57 |
Homepage: http://www.devrieze.net |
58 |
|
59 |
-- |
60 |
Paul de Vrieze |
61 |
Gentoo Developer |
62 |
Mail: pauldv@g.o |
63 |
Homepage: http://www.devrieze.net |