Re: [gentoo-user] update problems

[lee]

Neil Bothwick <neil@××××××××××.uk> writes:

> On Sat, 19 Sep 2015 21:36:06 +0200, lee wrote:
>
>> emerge -j 8 -a --update --newuse --deep --with-bdeps=y
>> @world
>>
>>  * IMPORTANT: 4 news items need reading for repository 'gentoo'.
>>  * Use eselect news read to view new items.
>>
>>
>> These are the packages that would be merged, in order:
>>
>> Calculating dependencies... done!
>>
>> !!! Multiple package instances within a single package slot have been
>> pulled !!! into the dependency graph, resulting in a slot conflict:
>>
>> dev-libs/boost:0
>>
>>   (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for
>> merge) pulled in by (no parents that aren't satisfied by other packages
>> in this slot)
>>
>>   (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for
>> merge) pulled in by dev-libs/boost:0/1.55.0= required by
>> (dev-libs/librevenge-0.0.2:0/0::gentoo, installed)
>> ^^^^^^^^^^ (and 2 more with the same problem)
>>
>> dev-util/boost-build:0
>>
>>   (dev-util/boost-build-1.55.0:0/0::gentoo, installed) pulled in by
>>     =dev-util/boost-build-1.55* required by
>> (dev-libs/boost-1.55.0-r2:0/1.55.0::gentoo, ebuild scheduled for merge)
>> ^
>> ^^^^^
>>
>>   (dev-util/boost-build-1.56.0:0/0::gentoo, ebuild scheduled for merge)
>> pulled in by =dev-util/boost-build-1.56* required by
>> (dev-libs/boost-1.56.0-r1:0/1.56.0::gentoo, ebuild scheduled for merge)
>> ^
>> ^^^^^
>>
>> media-video/ffmpeg:0
>>
>>   (media-video/ffmpeg-2.6.3:0/54.56.56::gentoo, ebuild scheduled for
>> merge) pulled in by (no parents that aren't satisfied by other packages
>> in this slot)
>>
>>   (media-video/ffmpeg-2.2.14:0/52.55.55::gentoo, installed) pulled in by
>>     media-video/ffmpeg:0/52.55.55=[vdpau] required by
>> (media-libs/mlt-0.9.0:0/0::gentoo, installed)
>> ^^^^^^^^^^^
> These are unimportant, it is simply portage telling you it is not
> updating some packages to the latest available and why. Personally, I
> believe this sort of output should only be shown when using --verbose.

Really?

That doesn't seem to be at all what it says.  It says, with huge
exclamation marks even:


"!!! Multiple package instances within a single package slot have been
pulled !!! into the dependency graph, resulting in a slot conflict:"


So obviously, something terrible is going on, preventing you from
installing required packages, and there is a dependency conflict which
cannot be solved because only one package of many can be used while
several are required in its place.

If this is irrelevant, then why doesn't it say that it is irrelevant?
Why was suggested that I remove boost to resolve an irrelevant conflict?

Should I always ignore such messages?


> [...]
>>
>> !!! The ebuild selected to satisfy "sci-libs/hdf5" has unmet
>> requirements.
>> - sci-libs/hdf5-1.8.14-r1::gentoo USE="cxx fortran threads zlib -debug
>> -examples -fortran2003 -mpi -static-libs -szip"
>>
>>   The following REQUIRED_USE flag constraints are unsatisfied:
>>     threads? ( !cxx !fortran )
>
> This is blocking you and the reason is given, if you have the threads
> flag on, cxx and fortran must be off. You have both threads and cxx on
> which won't work.

Well, it doesn't say which of the problems that have been reported are
the ones preventing me from going any further.  When I get error
messages, especially ones that appear to be very important (see all the
exclamation marks?), I usually try to find out what the problem is and
try to fix it, and starting with the important ones is one possible
approach.  That approach seems to be quite reasonable in this case,
considering that I'm trying to upgrade and get messages which appear to
be extremely important /and/ which tell me that I cannot upgrade, thus
apparently proving that their importance is more than merely apparent.

Then someone comes along and says that the messages with double-apparent
importance are actually irrelevant.  I find that very funny :)  Is that
a general thing with Gentoo, that something is the less important the
more important it seems to be, and that something that doesn't seem to
be important at all is the most important?

This one doesn't look very important, or does it?

>> Why can't we just update like we can with any other distribution but
>> have to run into dependency problems all the time instead?
>
> These aren't dependency problems, they are conflicting USE flags, a
> situation that cannot arise with a binary distro. If you want the
> flexibility that USE flags offer, you have to accept that not all
> combinations will work together.

That's fine --- I know I need to look into the USE flags here, the
message is somewhat clear.  I pasted it only for the sake of
completeness.

And I appreciate that kind of choice very much, to the point where I
don't really see a way back to binary distributions.  They don't make
sense anymore, though they still have their uses.

>> What do I do when I need to update /right now/ and find myself being
>> blocked with cryptic messages like the above that leave me stranded?
>
> That's the real problem, that the messages are so cryptic. The solution
> is simple, working out what needs to be done from the messages is not.

How about adding comments to such messages, like "You don't need to do
anything to be able to proceed." and "You need to fix this before you
could proceed."?

That's probably easy to do and would greatly help to distinguish between
important and irrelevant messages and make it easier to decide which
problem one wants to solve first.

>> Once I used 'emerge --sync', there is no way to turn it back to continue
>> to be able to install software if needed when the update cannot be
>> performed.  Updates simply need to work, there's no way around that.
>
> You can always roll back by masking the updates if necessary, and the
> old ebuilds are always available. Now that the tree is using git, it is
> probably possibly to sync back to yesterday if you need to.

Something like 'emerge --unsync' or 'emerge --syncto
<particular-git-hash>' would be much easier, taking you back to where
you were before you did an 'emerge --sync', or to when things were at
the particular hash.

The last sync I did before the one yesterday wasn't the day before
yesterday but over three months ago, so don't ask me today (or next
weekend or whenever I give it another try) when that exactly was.  See
what I mean?  Asking me to mask all packages to a certain point in time
is like asking me to do much of the package management by myself.

Should I make feature requests?


-- 
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us.  Finally, this fear has become reasonable.