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