Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
slot conflict madness
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
rochus
n00b
n00b


Joined: 06 Dec 2012
Posts: 7

PostPosted: Fri Oct 11, 2013 8:36 am    Post subject: slot conflict madness Reply with quote

Hello everyone,

I think I did not understand something about the slots and updating properly. I have two computers running gentoo, and even updating on a weekly basis leads to annoying slot conflicts that I have to solve manually. For instance, right now I have the following message (besides many others):

Code:

  (media-libs/x264-0.0.20130912::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (media-libs/x264-0.0.20130731::gentoo, ebuild scheduled for merge) pulled in by
    >=media-libs/x264-0.0.20090923:0/135= required by (media-video/vlc-2.0.7::gentoo, installed)


Interesstingly, x264-0.0.20130912 is already installed on the system - and so is vlc-2.0.7. Right now, they are living happily besides each other. Why is emerge telling me then, that they are in conflict? A little digging, like uninstalling vlc, trying to re-emerge it yields

Code:

  (media-libs/x264-0.0.20130912::gentoo, ebuild scheduled for merge) pulled in by
    (no parents that aren't satisfied by other packages in this slot)

  (media-libs/x264-0.0.20130912::gentoo, installed) pulled in by
    >=media-libs/x264-0.0.20111220:0/135= required by (media-plugins/gst-plugins-x264-1.0.10::gentoo, installed)


Aha, so the problem is not really vlc, but gst-plugins-x264. Updating this will reinstall x264-0.0.20130912 for whatever reason!
Why does portage not detect this kind of update-relationship? Am I required to hold emerge's hand each and every time I want to update my system? I can't remember that it was this annoying the same time last year.


Alas, another example. This time without the direct output because it's on a different machine. So, emul-linux-x86-gtklibs got an update to 20131008 and is pulled in for update by
Code:
emerge -uDavt --with-bdeps=y world
. However, this will lead to a conflict in emul-linux-x86-xlibs, because it is not automatically updated to the latest 20131008 version, but somehow emerge decides to leave that one at 20130224-r2 release. There are some more of the emul- packages which are not seen to be update-worthy. Okay, let's emerge --update --oneshot them first, like
Code:
 emerge --oneshot --update emul-linux-x86-xlibs emul-linux-x86-qtlibs
and so on. But no, emerge now tells me that there will be a slot conflict with emul-linux-x86-gtklibs because it wants to keep that at 20130224-r2. What the... Adding the gtklibs to the list of packages that I'd like to update solves this problem.

To me, this appears as the following: There is some Package A1 which is to be updated to A1-new. However, emerge can't udpate A1 because older versions of other packages, say A2-old, ..., An-old depend on A1-old. Updating A2, ..., An to A2-new, ... An-new won't work, because then A1-old will depend ond A2-old,...An-old. You see the point? Why didn't emerge figure out that if it updates A1,...,An to A1-new,...,An-new in one rush, all Ai packages would live happily ever after?

I'm really sick and tired of manually telling my emerge how to update things. If it detects that there is a new package of something, and an old version of another package for which an update is available depends on the old version of the package-to-be-updated, it should figure out if an update of the other package will solve that conflict.

Or am I missing something? May this be a problem of my world-file? I may be wrong in the understanding of some of the mechanisms of emerge and need to adapt. However it is a real waste of my time to figure out update-steps that emerge could easily figure out on its own.

Best
Back to top
View user's profile Send private message
nemectic
Apprentice
Apprentice


Joined: 20 Aug 2004
Posts: 181

PostPosted: Fri Oct 11, 2013 9:24 am    Post subject: Reply with quote

I'm guessing you're using unstable packages, ie. ~x86 or ~amd64 ?
I'm running stable for the first time in a while and it's rare I get conflicts these days.

Is your package.accept_keywords to blame? If you've accept keywords for a specific version of a program, it won't upgrade unless you also unmask the upgrade. You can get around that by removing the version number, ie.

Code:
media-libs/x264-0.0.20130912 ~amd64


The above would only unmask that specific version, whereas the below would unmask any version:

Code:
media-libs/x264 ~amd64
Back to top
View user's profile Send private message
rochus
n00b
n00b


Joined: 06 Dec 2012
Posts: 7

PostPosted: Fri Oct 11, 2013 9:29 am    Post subject: Reply with quote

You're right, I'm running ~amd64. My package.accept_keywords contains only sys-boot/grub:2 **, though. Maybe I should think about slowly moving to stable.
Back to top
View user's profile Send private message
nemectic
Apprentice
Apprentice


Joined: 20 Aug 2004
Posts: 181

PostPosted: Fri Oct 11, 2013 9:33 am    Post subject: Reply with quote

It's just one of the downsides of arch, I used it for a long time but don't have the time lately. It's very rare I get conflicts running stable, and I just use package.accept_keywords for the three(!) things I NEED from arch.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum