On 27/09/2013 13:18, Philip Webb wrote:
> 130927 Hinnerk van Bruinehsen wrote:
>> you are encountering a relatively new feature of portage
>> that is supposed to make revdep-rebuild & emerge @preserve-rebuild obsolete.
>> The logic is, that if you update a package, other packages
>> depending on this package will automatically rebuild to prevent breakage.
>> It seems that in your case portage "thinks" that one of that packages
>> depends on zsh-completion and pulls that in for rebuild,
>> which in turn, most likely via setuptools or PyQt4,
>> pulls libreoffice to rebuild.
>
> I have found sometimes that Portage wants to remerge LO or similar,
> but in fact the existing installed version continues to work regardless.
> Try remerging the other pkgs first & see if LO still functions as usual ;
> only if it doesn't do you need to remerge it.
Also consider how portage "knows" to rebuild something. In truth, it
doesn't know and has no way to just find out. It has to rely on data
added to the ebuild, and that's where this new feature called sub-slots
comes in.
In a nutshell, it's a DEPEND in reverse. LO has this one for example:
=dev-util/mdds-0.8*:=
That's a classic DEPEND, to install LO you must have mdds, so it gets
pulled in and built. From then on portage keeps mdds up to date and
knows it must use only version 0.8.something.
So far so goo. But what happens if mdds-0.8.1 introduces an API/ABI
change that breaks LO? Traditionally we had no way of dealing with this
in ebuilds and had to rely on revdep-rebuild and @preserved-rebuild,
both of which are ugly hacks (never mind that they work reliably).
Portage still had no way of knowing breakage would happen if it did it's
usual thing, so that's where subslots come in (the := notation)[1]
Basically, it say something like "LO DEPENDS on mdds, but also if the
installed version of mdds later changes, then LO needs to be rebuilt to
properly link against the new (and changed) version of mdds.
This only works right if the ebuild maintainer is on the ball, watches
Changelogs for the DEPENDS packages and put the proper metadata in the
ebuild. You can imagine how this can work out very very well when done
right, and if the maintainer makes a mistake (or doesn't clearly
understand how it works) it can cause many unneccessary rebuilds (but
not actually *break* stuff). Huge packages like LO with many
interconnected DEPENDS are always going to be the usual victim I'm afraid...
And then there's things that use poppler, boost, PyQT and pykde4 - a
similar effect is at work.
End result = your cpus will be kept nice and toasty warm doing lots of
compiles but actual breakage of the sort that led to revdep-rebuild
being developed should reduce dramatically. Some unneccessary rebuilds
are the price we pay for not having breakage.
In Helmut's specific case here, the cause seems to be python-exec. I
missed that one myself somehow so had no idea it was hanging around
biting folks.
[1] For clarity, I'll leave out explaining syntax here, that is
documented elsewhere.
--
Alan McKinnon
alan.mckin...@gmail.com
