[gentoo-dev] Re: Over using preserve_old_lib, don't do that

[Duncan]

Maciej Mrozowski posted on Thu, 15 Jul 2010 15:57:01 +0200 as excerpted:

> On Thursday 15 of July 2010 12:14:29 Duncan wrote:
>>
>> If I have FEATURE=-preserve-libs, that's what I want.  Exceptions
>> should be limited to what will break the toolchain (including
>> revdep-rebuild here, since that's what's normally used to get out of
>> the situation) itself.
>>
>> If there was a way to handle it so a general revdep-rebuild run would
>> still detect the preserved library as missing and do the necessary
>> rebuilds, it'd be one thing, but if the libraries are there, it figures
>> things are OK unless you've fed it that specific library, thereby
>> making a general revdep-rebuld run useless at the very task it was
>> designed to fix.
>>
>> Talking about which...  What about creating an eutils (or whatever)
>> function to handle the critical preservations, having it build a
>> centralized list of them somewhere, and having a revdep-rebuild mode
>> that will treat that list as if it had been fed in with --library on
>> the command line?  Make revdep-rebuild able to run this mode either on
>> its own, or as part of an otherwise general run, and then you can have
>> packages (or the package-manager itself, if it uses the list as well)
>> preserve libs as they wish, without interfering with the ability of
>> revdep- rebuild to detect and resolve the issues in a normal run.
>
> And what about using portage 2.2 and be done with it. I don't see the
> point in reinventing the wheel yet again.

As with Mike A, I've been running portage 2.2 for some time, and in fact, 
don't even have a world file any longer, as everything is in far more 
organized and easier to admin sets (thus bug #298298 on --depclean).

But preserved-libs caused me some serious problems and I feature-disabled 
it.  (If a package owns a file, it should do so consistently, everywhere 
it's installed, building the package should create it, and I should be 
able to dig its version as installed out of the binpkg tarball.)

> Imho, revdep-rebuild and all 'misc' tools requiring users' good will
> like python-updater should be obsolete and phased out in favour of
> package manager controlled mechanisms.

Ugh.  Automated can be useful, but don't get rid of the tools that allow 
one to do it step-by-step.  They're way too useful when something bugs out.

In my case, I always run emerge --update --deep --newuse when updating 
@system and @world, and always revdep-rebuild and --depclean afterward.  
While I do read the output portage spits out at the end of its emerges,  
having packages adopt earlier versions of their libraries and forcing me 
to do an additional library specific revdep-rebuild is forcing additional 
steps that the revdep-rebuild general run would normally find and fix 
entirely on its own -- only the adoption handling breaks that 
functionality.

For toolchain dependencies, that breakage is acceptable as it avoids worse 
alternatives.  But it shouldn't be happening for anything else (and I'd 
not make the exception Mike does for big-breakage libs, either, if the 
toolchain, including revdep-rebuild, works, it can fix it).

FWIW, since I'm running --as-needed in my ldflags and have lafilefixer 
post-install-hooked, I generally have far fewer rebuilds to do that those 
running without that.  Thus, the big breakages aren't nearly as big as 
they'd be otherwise, and with the exception of toolchain dependencies, 
that revdep-rebuild run at the end tends to be far less hassle than trying 
to cope with preserved-libs, and with breakage when libraries aren't in 
the binpkgs equery belongs says they're supposed to be in, etc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman