1 |
On Friday 08 June 2007 14:46:54 Enrico Weigelt wrote: |
2 |
> > Well, they still are different versions under the same packages |
3 |
> > from the same projects. |
4 |
> |
5 |
> Evolutionarily yes, technically no ;-P |
6 |
> They're in fact very diffrent, but provide an very similar |
7 |
> (almost the same) functionality. |
8 |
> |
9 |
> The problem is: upstream claims that newer evolutions steps |
10 |
> were newer versions, Gentoo takes it as it is and runs into |
11 |
> trouble, the attempt to fix this is slotting. |
12 |
|
13 |
Wtf. Newer versions are newer versions. No matter if they are fully backwards |
14 |
compatible or not. |
15 |
|
16 |
> If we simply would consider them as different packages, |
17 |
> the whole story would be trivial. We just have to decide at |
18 |
> which point a split has to be done. The whole complexity of |
19 |
> slotting and the still unsolved problems (ie. cleaning up) |
20 |
> could be dropped and dependency handling would be easy. |
21 |
|
22 |
The point is from the package manager point of view it would be trivial |
23 |
*because* the developers would have to do more of the work manually. I.e. the |
24 |
work of creating new packages, removing old ones and creating/updating |
25 |
virtuals where they currently just do version bumps and remove old ebuilds. |
26 |
|
27 |
I *really* don't see how adding seven versions of automake as seven packages |
28 |
in seven dirs plus adding a virtual that's provided by all seven of those |
29 |
versions is easier than just having seven versions in the same package with |
30 |
different slots. I also *really* don't see how adding a dep on =automake-1.4* |
31 |
or automake:1.4 is harder or more complex than automake1.4 (which currently |
32 |
would be an invalid package name anyway). |
33 |
|
34 |
The reason why cleaning cannot be done properly for packages in system or |
35 |
world is that the packages files that define the system set in the profiles |
36 |
and the world file don't support specifying slots. At this point it would be |
37 |
pretty trivial to add both, however, the problem with that is backwards |
38 |
compatibility with older versions of portage itself. Profiles aren't |
39 |
versioned like ebuilds with an EAPI so there are no means to assure that |
40 |
people upgrade portage before getting profiles that are incompatible with |
41 |
older versions of portage.. Even today we still occasionally get bug reports |
42 |
from people who --sync with <portage-2.0.51 which aren't compatible with the |
43 |
current profiles (bug #114798)... |
44 |
|
45 |
[SNIP] |
46 |
> Same with autoconf. The numbering is not that easy here, since |
47 |
> major breaks sometimes happen with minor version changes. So |
48 |
> we just have to look a bit more cafully. But still much simpler |
49 |
> as adjusting all these versioned dependencies which are necessary |
50 |
> with slotting. |
51 |
[SNIP] |
52 |
|
53 |
Indeed the real problem is that the current EAPI supports neither slot deps |
54 |
nor ranged deps (with the exception of the not too powerful =foo* syntax). |
55 |
|
56 |
> > > Gentoo has an strange magic for handling that, called "Slots". |
57 |
> > > They deeply break the linear version space. This makes handling |
58 |
> > > very tricky and requires much additional complexity. Some of |
59 |
> > > the other replies should make clear some prolems ... |
60 |
> > |
61 |
> > I have no idea what breaking 'the linear version space' means. |
62 |
[SNIP] |
63 |
> The Idea of this "linear" version space is that we can compare each |
64 |
> version with another one very easy. Additionally use the axiom that |
65 |
> higher versions are always successors of lower ones and backwards |
66 |
> compatible. In this situation the whole package management story |
67 |
> is really easy. Things like slots are not necessary. If we also take |
68 |
> in binary compatibility, revdev-rebuild is also not needed. Evrything |
69 |
> is strictly defined in the dependency graph. |
70 |
|
71 |
Wow. You're actually suggesting making a new package not only on API breakage |
72 |
but even on ABI breakage (otherwise revdep-rebuild would still be needed)? Do |
73 |
you *any* idea how many packages that would result in? It would be a |
74 |
maintenance nightmare. Keep in mind that CVS doesn't even support removing a |
75 |
package properly (with it's dirs). |
76 |
|
77 |
[SNIP] |
78 |
> > How is having a depend on =sys-devel/automake-1.4* or |
79 |
> > sys-devel/automake:1.4 any more complex than a depend on a separate |
80 |
> > packages named |
81 |
> > sys-devel/automake-1.4 ? |
82 |
> |
83 |
> What if now comes an 1.4.99 which is totally incompatible with the |
84 |
> other 1.4.* ? What do you do now ? |
85 |
|
86 |
Add a 1.4.99 slot? Just like you'd create a new package for it and add that to |
87 |
the virtual? |
88 |
|
89 |
> Drop that 1.4.99 ? |
90 |
> Give it another version, ie. some 1.5.* ? |
91 |
> Touch all depending patches to exclude 1.4.99 ? |
92 |
|
93 |
Huh? |
94 |
|
95 |
[SNIP] |
96 |
> > > No idea, why the responsible Gentoo-devs didn't just give |
97 |
> > > those incompatible packages different names, especially on |
98 |
> > > their own packages. AFAIK, java-config is made by Gentoo. |
99 |
> > > It would be trivial, just to call the 2.x version something |
100 |
> > > like java-config-2 ... perhaps too simple for them ? |
101 |
> > |
102 |
> > It still doesn't change the problem that if they have different |
103 |
> > files with the same name they need to install it in different |
104 |
> > places. That problem is just the same whether in slots or separate |
105 |
> > packages. |
106 |
> |
107 |
> Right. But that argument is neither for slots nor against. |
108 |
|
109 |
So that still leaves me without a clue about what problem making |
110 |
java-config-{1,2} different packages rather than slots would solve. |
111 |
|
112 |
[SNIP] |
113 |
> > --depclean does actually remove unneeded slots now for packages |
114 |
> > not in system or world. |
115 |
> |
116 |
> Well, I didn't prove it by myself - just took the input from this |
117 |
> list, where people stated it would NOT do it cleanly. |
118 |
|
119 |
The ability to do that has been added rather recently. |
120 |
|
121 |
> > By removing slotting you take away flexibility and make things |
122 |
> > in a source distribution harder. |
123 |
> |
124 |
> What flexibility do I take away exactly ? |
125 |
> And what exactly gets harder ? |
126 |
|
127 |
The ability to have more than one version of the same package installed at the |
128 |
same time. What is now a simple version bump (that happens to use a new slot) |
129 |
or cleaning of obsolete versions becomes packages additions and removals plus |
130 |
updates to virtuals. |
131 |
|
132 |
-- |
133 |
Bo Andresen |