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 attachment 15446 [details, diff] 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 attachment 15727 [details, diff] 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 attachment 15866 [details, diff] 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 attachment 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. ***
