| 1 |
Olivier Crête wrote: |
| 2 |
> On Sun, 2008-09-07 at 02:05 +0000, Jorge Manuel B. S. Vicetto wrote: |
| 3 |
> |
| 4 |
>> I've been thinking on a different method. With this method [3], we |
| 5 |
>> would keep using the <major>.<minor> slots (4.1, 4.2, etc) so we also |
| 6 |
>> wouldn't break the invariancy. We would allow users to select whether |
| 7 |
>> to have an FHS compliant install or not (the way to allow that still |
| 8 |
>> needs to be discussed) and we would set the prefix based on that. In |
| 9 |
>> case the user wants an FHS compliant install, the eclasses would block |
| 10 |
>> all kde packages on other slots - except 3.5 (uses other eclasses) and |
| 11 |
>> the live versions (for the above reason that it will always be |
| 12 |
>> installed under /usr/kde/<live-version>). |
| 13 |
>> |
| 14 |
> |
| 15 |
> The big problem with that idea is that upgrading from one version to |
| 16 |
> another will be very painful as portage will yell with a million |
| 17 |
> blockers. |
| 18 |
> |
| 19 |
> The only proper way to do it is to stop the /usr/kde madness for |
| 20 |
> everyone and just install everything in /usr like everyone else does, if |
| 21 |
> upstream wanted it to be parallel installable, they would have made it |
| 22 |
> that way (like gnome 1.x vs gnome 2.x). |
| 23 |
> |
| 24 |
I agree that this blocker idea is a non-starter. Personally I don't see |
| 25 |
what is wrong with the idea of having ebuilds in an overlay using the |
| 26 |
4.2 slot when it is time, developers/interested users test the ebuilds |
| 27 |
there, they can be in their own slot and when the release is made that |
| 28 |
are moved to slot 4 and put in the tree. |
| 29 |
|
| 30 |
There is nothing stopping us from having multiple slotted versions in |
| 31 |
overlays for testing purposes. We can only have one FHS compliant |
| 32 |
install. This means users do not build up multiple minor versions of KDE |
| 33 |
over the years, possibly not realising and not removing them. |
| 34 |
|
| 35 |
It also means third party KDE applications can be installed in /usr (as |
| 36 |
they always have been) and will simply relink to the latest version of |
| 37 |
kdelibs after an upgrade, rather than requiring a rebuild if you want |
| 38 |
them to use the latest kdelibs. I do not think we are removing that many |
| 39 |
options and I think for most users have one slot for KDE 4 would be most |
| 40 |
useful, I myself would rather use it that way. |
| 41 |
|
| 42 |
I am sure it would be possible to multiply slot Gnome minor versions too |
| 43 |
if the team really wanted to, I don't honestly think it is necessary for |
| 44 |
most people. For those that need it we can have slotted ebuilds in an |
| 45 |
overlays that could still coexist with the ebuilds in the tree. To offer |
| 46 |
ultimate flexibility being able to change the slot would be nice, but |
| 47 |
honestly I think having some ebuilds in an overlay with a different slot |
| 48 |
would be fine. |
| 49 |
|
| 50 |
Another point is that currently everything is still slotted, 4.0, 4.1 |
| 51 |
and scm versions. It is only when 4.2 is released that we will have an |
| 52 |
actual version that cannot be slotted if we stay with this scheme, which |
| 53 |
I think we should. |
| 54 |
|
| 55 |
Thanks, |
| 56 |
|
| 57 |
Marcus |
Archives