Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 326275 - eutils.eclass: add possibility to disable preserve_old_lib when FEATURES=-preserve-libs
Summary: eutils.eclass: add possibility to disable preserve_old_lib when FEATURES=-pre...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
: 333765 355461 (view as bug list)
Depends on:
Blocks: 326561
  Show dependency tree
 
Reported: 2010-06-30 08:40 UTC by Sebastian Luther (few)
Modified: 2011-02-18 20:22 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
EUTILS_NO_PRESERVE_OLD_LIBS support for preserve_old_libs (eutils.eclass-EUTILS_NO_PRESERVE_OLD_LIBS-support.patch,711 bytes, patch)
2010-07-01 05:37 UTC, Sebastian Luther (few)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian Luther (few) 2010-06-30 08:40:50 UTC
It would be nice if there where a way to not have libraries preserved in any case. There already is the FEATURES check for portage-2.2's preserve-libs. I'd like to see something similar that works without preserve-libs. Maybe a variable called EUTILS_NO_PRESERVE_OLD_LIBS.

use case:
I'm doing sort of unattended upgraded in a chroot. I have disabled preserve-libs there, because of the problem it causes from time to time. Instead I'm running revdep-rebuild after each update. The target system then uses the --rebuilt-binaries option to get the rebuild packages together with the updates that caused the rebuild. 
problems caused by preserve_old_lib:
* revdep-rebuild does not detect breakage
* packages keep being liked to old (possibly vulnerable) libraries
* the preserved library is contained in binary packages and if the target system hasn't disabled FEATURES="preserve-libs" there is no message from preserve_old_lib_notify.
Comment 1 SpanKY gentoo-dev 2010-06-30 23:01:35 UTC
unless there's a way of detecting it from the env, i'm not going to bother
Comment 2 Sebastian Luther (few) 2010-07-01 04:55:25 UTC
Your summary change is a bit confusing. preserve_old_libs is already disabled if FEATURES="preserve-libs" is enabled. What I want is a way to disable it in case of FEATURE="-preserve-libs".
Comment 3 Zac Medico gentoo-dev 2010-07-01 05:16:14 UTC
(In reply to comment #1)
> unless there's a way of detecting it from the env, i'm not going to bother

So you want to query the package manager to see if it supports preserve-libs or not? I suppose we could add a SUPPORTED_FEATURES variable to expose that info, but the EUTILS_NO_PRESERVE_OLD_LIBS approach also seems pretty reasonable.
Comment 4 Sebastian Luther (few) 2010-07-01 05:23:05 UTC
This is already part of preserve_old_libs:

# let portage worry about it
has preserve-libs ${FEATURES} && return 0
Comment 5 Sebastian Luther (few) 2010-07-01 05:37:57 UTC
Created attachment 237109 [details, diff]
EUTILS_NO_PRESERVE_OLD_LIBS support for preserve_old_libs
Comment 6 SpanKY gentoo-dev 2010-07-01 18:33:21 UTC
packages cannot relink to outdated libraries.  that has never been the case with the eutils.eclass or portage code.

i dont have a problem extending the code to maintain a state file of things it has preserved, but i'm still not inclined to add these disable hacks.
Comment 7 Sebastian Luther (few) 2010-07-01 19:55:15 UTC
(In reply to comment #6)
> packages cannot relink to outdated libraries.  that has never been the case
> with the eutils.eclass or portage code.

That's not what I'm concerned about. My problem is that it prevents an automatic rebuild by revdep-rebuild of packages linking against the old library because they are not broken. Instead I would have to read the logs on the binhost and pass the libraries to revdep-rebuild and delete them by hand afterwards. And then I still have to rebuild the binpkg of this library because the current binpkg contains the preserved library.

> i dont have a problem extending the code to maintain a state file of things it
> has preserved, but i'm still not inclined to add these disable hacks.
> 

Such a state file would allow automatic deletion of the old library, but a rebuild of the binpkg is still needed.

Adding files that do not really belong to a package to CONTENTS (and binpkgs) is a hack too. Please provide a way to disable this hack.

Comment 8 Jeremy Olexa (darkside) (RETIRED) archtester gentoo-dev Security 2010-07-02 02:12:11 UTC
Hi, I would like a way to disable preserve_old_lib() for binpkgs hosts too. I *know* that my build root is sane, but when I install the libpng-1.4* binpkg, the old .12 lib is preserved. This is an annoyance for me because I spent time to ensure the my build root had sane linking and that none of my binpkgs were broken. I don't need to use revdep-rebuild on my client, so why should the old lib be "preserved" ??

Thanks for considering.
Comment 9 SpanKY gentoo-dev 2010-07-02 18:12:13 UTC
there is no way that i know of to include the file in CONTENTS (which is what should happen) but exclude it from the binpkg (which is debatable).  i'm not going to break the former to support the latter.
Comment 10 Sebastian Luther (few) 2010-07-02 18:27:31 UTC
(In reply to comment #9)
> there is no way that i know of to include the file in CONTENTS (which is what
> should happen) but exclude it from the binpkg (which is debatable).  i'm not
> going to break the former to support the latter.
> 

There is probably none, but both are wrong imo.

Regarding your mail on then dev-ml:

>that bug report looks to me like the user not reading the output where they 
>have to delete the file themselves.

This is exactly the point. I do my updates automatically in a chroot and I couldn't care less if the linkage of half of all packages is broken for some time. I don't want to read the post install messages in the chroot. I want it as automatically as possible.
Comment 11 SpanKY gentoo-dev 2010-07-02 18:35:46 UTC
if it isnt in CONTENTS then the file is completely orphaned and an `emerge -C` would miss it, as would a normal upgrade.  so no, putting it CONTENTS is not wrong and is what we want.

as for automation, use portage-2.2 with preserve-libs if you want it.  or extend the current code to read the existing vdb entries which document all the tracked ELF dependencies.
Comment 12 Sebastian Luther (few) 2010-07-02 18:49:25 UTC
(In reply to comment #11)
> if it isnt in CONTENTS then the file is completely orphaned and an `emerge -C`
> would miss it, as would a normal upgrade.  so no, putting it CONTENTS is not
> wrong and is what we want.

Ok, you have point.

> 
> as for automation, use portage-2.2 with preserve-libs if you want it. 

I used to do that, but its bugs raised too often the need for manual fixing.

> or
> extend the current code to read the existing vdb entries which document all
> the tracked ELF dependencies.

Not sure where you want to go here.

Comment 13 SpanKY gentoo-dev 2010-07-02 19:08:26 UTC
add to the for loop in preserve_old_lib:
find /var/db/pkg -name NEEDED '!' -size 0 -exec grep -q "${lib}" {} + || continue
Comment 14 Sebastian Luther (few) 2010-07-02 19:16:48 UTC
(In reply to comment #13)
> add to the for loop in preserve_old_lib:
> find /var/db/pkg -name NEEDED '!' -size 0 -exec grep -q "${lib}" {} + ||
> continue
> 

If I understand correctly, this preserves the library only if it is really needed (instead of always). That's still not what I want. 

I don't want the library preserved even if that means that the consumer will be broken. Only this way revdep-rebuild will detect that the consumer needs to be rebuild.
Comment 15 SpanKY gentoo-dev 2010-07-02 19:27:17 UTC
i'm still not interested in supporting that.  i havent seen a compelling reason for me to spend time on adding what is ultimately a completely unsupported operating mode.
Comment 16 Sebastian Luther (few) 2010-07-02 19:45:48 UTC
(In reply to comment #15)
> i'm still not interested in supporting that.  i havent seen a compelling reason
> for me to spend time on adding what is ultimately a completely unsupported
> operating mode.
> 

In this case, I'll give up now. Thanks for your time.
Comment 17 Sebastian Luther (few) 2010-07-05 16:59:58 UTC
Having used a hack to disable preserve_old_libs for some days, I just realized that having gcc is more annoying than I thought.

I'm now using my own version of preserve_old_lib() that writes to a database which files got preserved, like you suggested in comment 6. I'm then using a script to run all the needed steps.
Comment 18 Jacob Godserv 2010-07-16 18:49:01 UTC
Background as I understand it: bug #326561 is a result of this bug, and has caused more complications than what it might be worth.

I posted this comment there, and I think it should be here as well:

---- 

> It's also worth noting that the preserve_old_lib issue that brought this whole
> thing up could be solved by making preserve_old_lib cease to query FEATURES (as
> required by PMS), and using a separate environment variable to control
> preserve_old_lib (as suggested in bug 326275).

_This_ makes sense to me. If someone writes code that breaks a user's machine because it breaks PMS, it seems logical to immediately rewrite the code in question to obey PMS so it doesn't break anything, rather than trying to work around PMS-invalid code.
Comment 19 Samuli Suominen (RETIRED) gentoo-dev 2010-08-21 10:19:03 UTC
*** Bug 333765 has been marked as a duplicate of this bug. ***
Comment 20 Łukasz Michalik 2011-02-18 20:22:55 UTC
*** Bug 355461 has been marked as a duplicate of this bug. ***