How to upgrade packages in older SLOTs?

Message

Gaspode · Post by **Gaspode** » Mon Jun 13, 2005 9:01 am

I am currently fooling around with the (unofficial) KDE-SVN ebuilds and trying if the slotting works as expected. As it turns out, it does not... I don't think this is a problem with these particular ebuilds though.

I installed akode-7 parallel to the existing akode-3.4.1, noting that there is already a newer version akode-3.4.1-r1 around which has NOT been installed. After installation, equery shows the following:

Code: Select all

[ Searching for package 'akode' in all categories among: ]
 * installed packages
[I--] [  ] kde-base/akode-3.4.1 (3.4)
[I--] [  ] kde-base/akode-7 (7.0)
 * Portage tree (/usr/portage)
[-P-] [ ~] kde-base/akode-3.4.0 (3.4)
[-P-] [ ~] kde-base/akode-3.4.1-r1 (3.4)
 * overlay tree (/usr/local/portage /usr/local/overlays/kde-live)
[--O] [  ] kde-base/akode-7 (7.0)

The expected behavior for an upgrade now would be that akode-3.4.1 gets updated to akode-3.4.1-r1, since there is a newer version for this slot, right? But that's not what happens:

Code: Select all

[~] # emerge -ua akode

These are the packages that I would merge, in order:

Calculating dependencies ...done!

Nothing to merge

So, probably because akode-7 is newer than akode-3.4.1-r1, Portage just ignores the newer version for the 3.4-slot...

Of course, slotting does not make too much sense if the newest slot blocks upgrading of the older slots. Is this a general problem with Portage, or is it just the inofficial kde-7 ebuilds? If the former, is there any way to work around it? I would love playing with KDE-SVN, but I want to have a working and up-to-date 3.4 next to it.

Oh, just in case: Before akode-7 was installed, I ran 'emerge -ua akode', and Portage wanted to upgrade the package to 3.4.1-r1. So it works as long as no newer slot is taken.

Post by **kallamej** » Mon Jun 13, 2005 10:13 am

If nothing depends specifically on the 3.4 slotted version it will not be updated as the higher version fulfills the dependency. You'll get the same behaviour if the package is in your world file, iirc.

Gaspode · Post by **Gaspode** » Mon Jun 13, 2005 2:47 pm

kallamej wrote:If nothing depends specifically on the 3.4 slotted version it will not be updated as the higher version fulfills the dependency. You'll get the same behaviour if the package is in your world file, iirc.

That's what I suspected... but is this a bug or a feature? I can't imagine a situation where one would like to have multiple versions of a package in different slots installed, but not update the versions in lower slots automatically if newer versions are available.

Putting or removing the package from the world file does not seem to make a difference. One real nasty work-around seems to be to (temporarily) remove the overlay, then run the supposedly evil and deprecated emerge --upgradeonly. But I don't think that's what one really wants to do.

If there is no "legal", clean solution for this problem, this should maybe filed as a bug...

Any other opinions/hints?

TrueDFX · Post by **TrueDFX** » Mon Jun 13, 2005 3:03 pm

Not sure about the bug or feature bit, but you can upgrade the older version with emerge -av '=akode-3.4*'

Gaspode · Post by **Gaspode** » Mon Jun 13, 2005 3:13 pm

TrueDFX wrote:Not sure about the bug or feature bit, but you can upgrade the older version with emerge -av '=akode-3.4*'

OK, this works for single packages; is there anyway to have them automatically upgraded? An 'emerge -uDav world' should, IMHO, upgrade everything that's applicable, including slotted packages.

At the moment I see no way to keep slotted packages current without explicitly knowing their names (which, in a system with a lot of slotted packages such as KDE meta ebuilds, is just not an option).

TrueDFX · Post by **TrueDFX** » Mon Jun 13, 2005 3:21 pm

I think, that if a specific version is needed for a package (such as arts-1.3*), emerge -uD will catch upgrades - assuming the package that depends on it is also caught. So what you could do is create a metapackage in an overlay directory that pulls in =kde-base/kde-3.3* (for example), and emerge that. Then, emerge -uD world should update all of your KDE stuff, because it looks for newer versions of kde-3.3*, rather than newer versions of kde (from your world file).

Yeah, it's a kludge, and if there's a cleaner solution I'd certainly be interested as well.

chetan13 · Post by **chetan13** » Sat Oct 08, 2005 7:48 am

Till i read this thread, i thought there wasn't an aspect of package management(atleast of those i could imagine) that portage couldn't handle. Is this bug fixed? I just remove kde-3.4* in favour of kde-7* so i can't test.