Alan McKinnon <alan.mckin...@gmail.com> wrote:
>
> No, no problem whatsoever. emerge @preserved -rebuild is my preferred
> method, I find it vastly superior to sub-slot operators which

It is neither superior nor inferior.

It is an unrelated mechanism which will have less to do
once subslot dependencies are more widespread.

However, some dependencies in the tree are not yet EAPI5,
and moreover, some dependencies in some overlays can never
make use of subslots if these subslots are not in the
corresponding dependencies of the gentoo tree (e.g. because
these subslots are not needed for the packages *in* the tree).

So revdep-rebuild will never become obsolete.

> The problem seems to be that preserved-rebuild and revdep-rebuild detect
> actual breakage and fix what is really wrong right now.

The problem is that preserved-rebuild and revdep-rebuild only
detect one particular type of breakage.

Here is a real-world example: One day I realized that pdflatex
crashed for me, and neither revdep-rebuild found something
nor reemerge of texlive-core helped.

I spent several hours of debugging and finally found that the
cause was a poppler -r1 fix which tacitly changed some ABI which
caused luatex to crash.  So actually, it was luatex which needed
to be reemerged.

The bug was closed as INVALID because the developer had the
opinion that everybody knows that if poppler has any minor bump,
all packages depending on poppler have to be reemerged.
In fact, these days there were no mechanisms (except for
perhaps a pkg_postinst message of the form "reemerge everything
depending on poppler") which could inform the user what should
be done so closing this bug was the only thing which could be done.

Similar issues occured regularly with webdav-neon: Although
the ABI was changed, the libraries version number was not,
and so e.g. subversion tacitly crashed or malfunctioned.
Revdep-rebuild could never find anything in such a situtation.

As another, well-known, example, probably most of us ran
into the issue of having to reemerge X drivers after an xorg bump
or otherwise keyboard and mouse just will not work.

I am very glad that now such issues do not occur anymore:
After a while, one knows the problematic packages, but from
time to time new unexpected issues like the above examples
arise.

> Subslots seem to try and avoid breakage and depend heavily on amount of
> clue from the dev (a highly variable quantity)

Not much clue: If the dev is in doubt, he just bumps the subslot.
This way things are guaranteed to work, although some rebuilds
caused by the bump might be unnecessary.
But *not* bumping should really be done only if the developer is
sure that there is no ABI change.

In case of poppler, things are even more complicated, because
there is one library which regularly changes ABI, although that
particular library is not consumed by most packages.  So actually
subslots are not fine enough to avoid unnecessary rebuilds, or
the poppler package should be split into two to avoid
unnecessary rebuilds.

>> * do you trust the other methods like subslots or preserved-rebuild to
>> work reliably? (as in: do you still use revdep-rebuild?)
>
> yes, revdep-rebuild is my plan C.

Indeed, as mentioned above, subslots will never replace
revdep-rebuild.
preserved-rebuild is meant to replace it, but there might
be some corner cases where it does not detect a change (e.g.
if some important things are done only in the live system).

> usually itcompletes in about 40 secodns and is clean.

For me, it needs about 10-20 minutes if everything is clean.

But then again, also reemerging libreoffice needs 2-3 days,
and it would be a week or even infinite without ccache
(because for unknown reasons, the first emerge attempts
usually fail non-reproducible).

>> If you want my opinion on subslots:
>> # grep EMERGE_DEFAULT_OPTS /etc/portage/make.conf
>> EMERGE_DEFAULT_OPTS="--ignore-built-slot-operator-deps=y"

A different user interface would be preferrable:
Something like FEATURES=show-built-slot-operator-deps
which would *show* what would need to be rebuilt even
if the above EMERGE_DEFAULT_OPTS is used.
This is then something which users with less powerful
machines like me can put into their make.conf and then
decide from case to case whether/when to rebuild.

Or even better: In --ask mode, one could ask the user
in addition for those packages only pulled in by
subslot deps.

This way users with not so powerful machines would be
informed regularly but would not be forced to call
emerge twice or more times just to get the information
(which meanwhile is really a time issue).

The current way of reemerging subslots by default
might (and IMHO should) be kept, anyway.


Reply via email to