Bugzilla Bug 4698

Me and drobbins were talking about this earlier this morning.  When you do an
'emerge --update foo-pkg' and foo-pkg has a number of different versions, all
slotted, it only updates the 'latest' slot--i.e. 2 instead of 1.2.  This is a
problem, since the existence of a SLOTted 1.2 version on the machine implies
that it is being used and should be updated regularly.  You can still explicitly
state the updated version, of course, but 'emerge --update' should catch all of
the updates of all of the SLOTs.

I also tentatively suggest that 'emerge --update' NOT work on packages with
SLOT="" if other SLOTs are present.  This is to enforce the current standard of
making sure that SLOT has a value other than NULL, and is another quick check
that can get rid of some developer error.  If other SLOTs are not present,
however, it should do an update as normal, since it's assumed that we simply
haven't gotten around to SLOTting those ebuilds yet.

cc'ing drobbins per our conversation.

Me, too, suffered from it today.
If one relies on "update world" only, it is very hard to find out which packages
are really affected and need manual updating to keep the system current (there
were four of them on my system, among them glib and gtk+).

Please make "emerge world" work on all slots!

Nick, not sure if this is still an issue.

Seems fine to me with portage-2.0.46, although it does have a small cosmetic
error ...

-----------
nosferatu env.d # emerge -up --deep world

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

Calculating world dependencies ...done!

[ebuild    UD] x11-libs/gtk+-1.2.10-r10 [2.2.0-r0]
[ebuild    U ] x11-libs/gtk+-2.2.0-r1 [2.2.0-r0]

nosferatu env.d # 

What's --deep?

I've 2.0.46, but it is neither in the man page nor in the usage message of emerge.

Nick, I thought you added the '--deep' switch to the docs?

I just added --deep to the man page; someone can gladly add it to the actual
internal executable documentation.

*** Bug 13968 has been marked as a duplicate of this bug. ***

*** Bug 16639 has been marked as a duplicate of this bug. ***

*** Bug 20061 has been marked as a duplicate of this bug. ***

*** Bug 11888 has been marked as a duplicate of this bug. ***

There should be also a way to merge only specific slot - e.g. using
emerge x11-libs/gtk+:1
or
x11-libs/gtk+/1
or something similar.

This is needed for my script revdep-debuild (gentoolkit) (see comment for bug 22161).

I have the following problem with portage 2.0.48-r1:

The output of "emerge -up --deep world" correctly suggests that I update the "slot 1" version of gnome-base/gconf:

...
[ebuild    U ] gnome-base/gconf-1.0.8-r5 [2.2.0]
...

The output of "etcat -v ^gconf$" supports that as well:

*  gnome-base/gconf :
        [  I] gnome-base/gconf-1.0.8-r3 (1)
        [M~ ] gnome-base/gconf-1.0.8-r4 (1)
        [   ] gnome-base/gconf-1.0.8-r5 (1)
        [  I] gnome-base/gconf-2.2.0 (2)
        [M~ ] gnome-base/gconf-2.2.1 (2)

However, if I issue "emerge -up gconf" I get:

These are the packages that I would merge, in order:
 
Calculating dependencies ...done!

So I take it that update world acts correctly while updating a single, slotted version of a package does not.

*** Bug 24612 has been marked as a duplicate of this bug. ***

*** Bug 24672 has been marked as a duplicate of this bug. ***

Apache was the last thing I wanted to have this problem.

This seems related, I'm not sure if it warrents a new bug or not.

The SLOT mechanism seems to be causing confusion in many packages (Apache is an example) where you have one SLOT installed, and portage when doing an emerge -p world is wanting to install another SLOT due to a higher version number (not upgrade, but install beside it). Different SLOTs should be different upgrade paths, and that's what the documentation seems to imply:

http://www.gentoo.org/doc/en/portage-manual.xml
"Most distributions and ports systems tend to have a "freetype" package for freetype 1.x and "freetype2" for 2.x. We consider this approach a sign of a fundamentally broken package management system. We simply assigned the SLOT number 1 to the first and number 2 to the second. With this information Portage can track both versions and upgrade both versions if updates to the respective upstream branches are made."

*** Bug 25040 has been marked as a duplicate of this bug. ***

*** Bug 23034 has been marked as a duplicate of this bug. ***

I made a patch for fixing this bug.
But I'm not sure it's correct because SLOT is very complicated ;)

Please test it and do feedback.

Created an attachment (id=15446) [details]
the patch for emerge/portage.py

*** Bug 26139 has been marked as a duplicate of this bug. ***

I have some problems with the patch, I'll show you some examples (only the
important parts):

Without patch:

# emerge -p =sys-devel/gcc-2.95.3-r7
!!! all ebuilds that could satisfy "=sys-devel/gcc-2.95.3-r7" have been masked.

# emerge -p /usr/portage/sys-devel/gcc/gcc-2.95.3-r7.ebuild
[ebuild     U ] sys-devel/gcc-2.95.3-r7 [3.2.3-r1] 

# emerge -p apache
[ebuild  N    ] net-www/apache-2.0.47  

With patch:
# emerge -p =sys-devel/gcc-2.95.3-r7
(nothing)

# emerge /usr/portage/sys-devel/gcc/gcc-2.95.3-r7.ebuild
[ebuild     U-] sys-devel/gcc-2.95.3-r7  

# emerge -p apache
[ebuild  N    ] net-www/apache-1.3.28  
[ebuild  N    ] net-www/apache-2.0.47  

So the output for the gcc thing is wrong and inconsistent, and I don't like
behavior for apache:
It is nice to show that there are two SLOTs available, but IMO there are few
people actually using both versions parallel and the behavior is not consistent
with dependency handling. I'd prefer portage to abort in such a situation (when
two SLOTs are available with no preference) and print a message that the user
has to choose a specific version. It would also confuse people that don't know
about SLOT as there is no indication in the output.

hi, Marius
Thank you for reply.

I fixed a bug that emerge is normal end when a package doesn't exist.

And I modified as you said about second problem, which i don't think problem.
I'm not sure which is best solution.

Examples, (English message is just sample. I'm not native English, as you know)
# emerge -p apache

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

Calculating dependencies ...done!
[multi B     ] net-www/apache-1.3.28 [1]
[multi B     ] net-www/apache-2.0.47 [2]

You need to select one version
Example, "emerge =net-www/apache-2.0.47"
You can install both of them, if you emerge twice.

Created an attachment (id=15727) [details]
patch for portage.py/emerge

hmm, the blocking stuff is nice, but there are still several problems:
- all kernel versions are slotted, so we get the blocking message for every kernel emerge
- the gcc problem in my last post still exists
- when I want to emerge a SLOTed without -p, the error message uses tha lowest available version
- I get a traceback on emerge -ep world:
\Traceback (most recent call last):
  File "/usr/bin/emerge", line 2065, in ?
    if not mydepgraph.xcreate(myaction):
  File "/usr/bin/emerge", line 989, in xcreate
    if not self.create(myk):
  File "/usr/bin/emerge", line 682, in create
    if not self.select_dep("/",mydep["/"],myparent=mp):
  File "/usr/bin/emerge", line 885, in select_dep
    if not self.create(myk,myparent):
  File "/usr/bin/emerge", line 682, in create
    if not self.select_dep("/",mydep["/"],myparent=mp):
  File "/usr/bin/emerge", line 885, in select_dep
    if not self.create(myk,myparent):
  File "/usr/bin/emerge", line 695, in create
    if not self.select_dep(myroot,edepend["PDEPEND"]):
  File "/usr/bin/emerge", line 805, in select_dep
    print "\nemerge: there are no masked or unmasked ebuilds to satisfy "+arg+"."
TypeError: cannot concatenate 'str' and 'NoneType' objects

Please make also possible to update specific slot only, for example by:
emerge -n -u net-www/apache:1

This feature will be very useful for revdep-rebuild.

*** Bug 26210 has been marked as a duplicate of this bug. ***

i dont see how doing :1 and -1* is any easier ... 
plus, i dont really see how revdep-rebuild would benefit from the change ... 

Created an attachment (id=15866) [details]
patch for portage.py/emerge

>- all kernel versions are slotted, so we get the blocking message for every
kernel emerge

Is this a problem?

>- the gcc problem in my last post still exists
Fixed

>- when I want to emerge a SLOTed without -p, the error message uses tha lowest
available version

Which package is it?

>- I get a traceback on emerge -ep world:
Fixed

hi, Stanislav

I thought a way to specify SLOT by emerge before.
example
# emerge apache:1
DEPEND="net-www/apache:1"
etc...

But if we discuss it here, this bug will be complicated.
I think we should discuss about this in another new bug.

emerge apache:1 does not work for me:
Calculating dependencies
emerge: there are no masked or unmasked ebuilds to satisfy "apache:1".
 
!!! Error calculating dependencies. Please correct.

Separate bug, which explains, why revdep-rebuild needs SLOTted emerge command: see bug 22161. I have added new comment.

>>- all kernel versions are slotted, so we get the blocking message for every
>>  kernel emerge
> Is this a problem?

It is a problem as either world updates would not include kernel updates anymore or world updates will break unless you update your kernel before. Both cases would be very irritating and annoying for users. The main issue is that EVERY single version is in its own SLOT.
Ok, that's the theory, the actual results are even more confusing. See the attachment of the output of emerge -upvD world with patched and unpatched portage. Why is it upgrading ac-sources to a different SLOT, downgrading nautilus and gdm and upgrading gdm later?

>>- when I want to emerge a SLOTed package without -p, the error message uses
>>  the lowest available version
> Which package is it?

Tested with mm-sources and other packages (don't remember all of them).

Created an attachment (id=16126) [details]
output of emerge -upvD world

I think it's this story.

1. You already installed gnome-1.4.
2. There is gnome-1.4-r3 in Portage tree.
3. emerge will install gnome-1.4-r3 even if gnome-2.* is installed.
4. gnome-base/gnome-1.4-r3 depends on "<gnome-base/gdm-2.4"
5. you already installed gdm-2.4.1.4
6. gdm has no SLOT(all SLOT="0")
7. then emerge will merge gdm-2.2.5.4 and unmerge gdm-2.4.1.4

The patched emerge is correct, I think. The unpatched ebuild will not do No3-7.

And I think it's also gnome ebuilds bug because gnome-base/gnome
has SLOT but gnome-base/{gdm,nautilus} have no SLOT.

What do you think?

I think you're right about the gnome/gdm stuff, a lot of the gnome/gtk stuff
doesn't use SLOTs where it should. The kernel thing is still confusing me
though, why does it upgrade to a different SLOT ?

kernel sources? because kernel sources can co-exist on disk. Slots are for
packages that can co-exist with other versions of the same package on disk (and
still function correctly.)

Sure they can, I'm wondering how the patch affects kernels or other things were
each version is in a different SLOT. As I understand it packages should only be
upgraded in their own slot. But I've found a possible explanation for this:
Maybe the kernel ws an exception because it was in the world file. But on the
contrary mm-sources was upgraded without the patch, but not with the patch :-/
So I have one kernel package upgraded and one not upgraded which is clearly
incorrect.

While you're at it: IMHO emerge -update also should _not_ install packages from
currently not installed slots. i.e. I use ~x86 and "emerge -DUu world" wants to
upgrade KDE 3.2.2 -> 3.2.3 in slot 3.2 and install new kde 3.3.0_alpha1
packages in slot 3.3. The latter shouldn't only happen if the version from the
new slot is a dependency of a new version of an allready installed package.

*** Bug 88495 has been marked as a duplicate of this bug. ***

Please take into account that there can be slot issues with one and the same
package and it's slotted (second level) dependencies, too. >> Bug 98425

*** Bug 28380 has been marked as a duplicate of this bug. ***

*** Bug 47345 has been marked as a duplicate of this bug. ***

*** Bug 97886 has been marked as a duplicate of this bug. ***

*** Bug 112933 has been marked as a duplicate of this bug. ***

What is the status of this bug?  Is there any plan to ever fix it?

Because "emerge --update --deep world" doesn't seem to update older slots,
is there any alternative command that will find all such older slots that
need updating and update them?  (Or maybe also determine that some older
slots are no longer needed and recommend their removal?)

(In reply to comment #46)
> What is the status of this bug?  Is there any plan to ever fix it?
> 
> Because "emerge --update --deep world" doesn't seem to update older slots,
> is there any alternative command that will find all such older slots that
> need updating and update them?  (Or maybe also determine that some older
> slots are no longer needed and recommend their removal?)
> 

There is no alternative and it depends on a new resolver.  We have plans for a
new resolver, but no code yet.

*** Bug 119210 has been marked as a duplicate of this bug. ***

Just got tripped up with this with gcc (slots 3.4 and 4.0).  Sigh.  That'll
teach me to not read up on known slot problems.

I only realised there was a problem when I did "equery l gcc" and found that my
3.4 gcc installation was actually masked (or, more precisely, didn't exist in
portage any more).

*** Bug 128118 has been marked as a duplicate of this bug. ***

Is there some new status of this item in new portage? I cannot see any
difference - for example sun-jdk 1.4 is still ignored in updates, if you have
1.5 installed. Some plans to have it?

*** Bug 128644 has been marked as a duplicate of this bug. ***

*** Bug 129600 has been marked as a duplicate of this bug. ***

I've just had this problem - I have a KDE installed in slot 7, and found that
slot 3.5 hasn't been updated for sometime. attempting to move to GCC 4.1.1
resulting in revdep-rebuilt trying to emerge --oneshot a whole load of KDE-3.5
packages that are no longer in portage, despite the fact I've been regular with
my emerge --update's.

The fact that this problem with slots not being upgraded isn't mentioned at all
in the emerge man page worries me a little - this issue could result in
outdated packages on your system, and this in turn surely could result in
security issues being present. (take for example in my case, the various
security issues in KDM -  the KDE login manager).

Anyway, I solved my problem doing this (i'm sure htis command could be improved
upon, effeciency wans't in mind here, I just wanted to get it done ;) )

# equery list --duplicates | grep "\(3.5\)" | grep kde-base | sed
"s/\(.*-3.5\).*/\1/" | sed "s/\(.*\)/=\1*/" | xargs emerge --update -pv 

Missed the bug's fourth birthday :(

(In reply to comment #55)
> Missed the bug's fourth birthday :(

Fear not, there will be many more to come... it's still a "new" bug.

*** Bug 140293 has been marked as a duplicate of this bug. ***

Surely one of the portage developers would love to take on this delightful
task?  If only in honour of its fourth birthday?  I really /did/ have a
conversation with drobbins back then about how it was incorrect behaviour ...
:)

dep resolver donations are welcome.

In the case of `emerge -uD world`, it seems like we'd need support for slot
deps in the world set. The alternative would be to simply use an "all" package
set (bug 96088) to pull in the lower slots.

The case of `emerge -u <atom>` is relatively easy to support since it only
needs to see which slots are matched by the command (depending on which slots
are installed) and pull in the appropriate updates.

*** Bug 140591 has been marked as a duplicate of this bug. ***

*** Bug 144622 has been marked as a duplicate of this bug. ***

*** Bug 145497 has been marked as a duplicate of this bug. ***

*** Bug 147093 has been marked as a duplicate of this bug. ***

According to Brian Harring, it's not the highest SLOT it's the highest package
version.

Enjoy your bug spam. (Sorry)

Just curious, when is this going to be fixed? This "feature" is a PITA on my
current revdep-rebuild run (due to libssl/libcrypto ABI breakage), _many_

emerge: there are no ebuilds to satisfy "=foo/bar-1.2.3-r4".

to be resolved manually by emerging the newest ebuild in that slot (and having
to re-run revdep-rebuild each time, or manually edit the .revdep-rebuild tmp
files).

This bug is really annoying, and as it is in bugzilla for more than four
years(!) now, I wonder whether it will be adressed some day (there were already
patches for earlier Portage versions, see attachment list!) or whether the
Portage team's efforts continue going into groundbreaking features like
configurable colouring (see current GWN).

For those wondering when this bug will be fixed, please note that bug 93469 is
a dependency that is blocking progress on this bug.

Hmm, wrt Comment #68: I can see that the two are related, but I can't see that
SLOT dependencies *have* to be done first.

If I have SLOT a and SLOT b of a package installed (b > a), then this bug is
(as far as my understanding, and also fitting in with the new exciting summary
line) all about the fact that updates to SLOT a do not get picked up properly. 
That has got nothing to do with SLOT dependencies (although having SLOT
dependencies may make this problem go away).

(In reply to comment #69)
> Hmm, wrt Comment #68: I can see that the two are related, but I can't see that
> SLOT dependencies *have* to be done first.

The problem is that packages are pulled into the dependency graph as dependency
atoms.  Without slot support in the dependency atoms, it's impossible to
restrict an upgrade to a specific slot.  This results in the highest slot being
pulled in when the highest version within a lower slot would have been the
desired behavior.

This is fixed in svn r4595.

This has been released in 2.1.2_pre2-r4.

And it only took a little over four years!  Yeah!  Thanks, guys.  You rock. 
(I'm not being sarcastic with that; this has been a personal pet peeve of mine
since I was a dev, hence the bug.)

Sorry to spoil the fun, but doesn't seem 100% fixed to me.
World looks fine:
# emerge -up world
Calculating world dependencies... done!
[ebuild     U ] dev-java/sun-jdk-1.6.0.0_beta101 [1.6.0.0_beta100]

But package directly...

# emerge -p sun-jdk
Calculating dependencies... done!
[ebuild   Rf  ] dev-java/sun-jdk-1.7.0.0_alpha01

# emerge -up sun-jdk
Calculating dependencies... done!
(nothing to merge)

Tested with 2.1.2_pre2-r4 and -r5.

(In reply to comment #74)
> # emerge -up sun-jdk
> Calculating dependencies... done!
> (nothing to merge)

I think that behavior is fine.  Otherwise we'd be treating sun-jdk as a
"greedy" atom (matching all slots instead of the highest version).  If you're
not using the world or system set, then you should run a command like `emerge
-up sun-jdk:1.6`.

We could add a --greedy option to enable greedy matches on atoms, but that
would be a separate bug.  The world and system sets are greedy by nature.

Well, I don't see why not make it greedy by default? Original comment 0 talks
about 'emerge --update foo-pkg' and you in comment 60 say it's easy :)

(In reply to comment #77)
> Well, I don't see why not make it greedy by default? Original comment 0 talks
> about 'emerge --update foo-pkg' and you in comment 60 say it's easy :)

So, --update should imply --greedy?  It's never been greedy like that before,
so it will probably catch lots of people by surprise.  We'll have to provide a
way for them to disable the greedy behavior, as well.  We could make it an
option similar to --with-bdeps, having y and n choices.

(In reply to comment #78)
> So, --update should imply --greedy?  It's never been greedy like that before,
> so it will probably catch lots of people by surprise.

So? World update also wasn't greedy before, and now it is. So why not make
package update consistent. I honestly don't believe anybody would mind or be
badly surprised that package updates properly when he asks it to update.

The meaning of this bug has become too overloaded over the years.  I'm closing
this as fixed via the greedy behavior of system and world sets.  Any additional
greedy behavior should be treated as a separate feature request (a different
bug).

(In reply to comment #80)
> Any additional greedy behavior should be treated as a separate feature request (a different bug).

Your wish is my command ;-) bug #150361

*** Bug 159626 has been marked as a duplicate of this bug. ***

*** Bug 164634 has been marked as a duplicate of this bug. ***