FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 07-02-2010, 05:51 AM
Samuli Suominen
 
Default Over using preserve_old_lib, don't do that

I've recently stumbled upon several packages unnecessarily using old
preserve_old_lib feature from eutils.eclass, namely:

libgnomekbd
libproxy

And then users hit issues like this:

https://bugs.gentoo.org/show_bug.cgi?id=326517#c5

Please only use the preserve_old_lib function in case of breaking:

- base-system
- toolchain
- or the library is so widely used that revdep-rebuilding the system
would be nearly impossible without having the old lib around since
revdep-rebuild (emerge) can't get the emerge ordering right (because of
overlinking and lack of asneeded by default, namely jpeg and png comes
into mind)

It's a hack, not a solution

Thanks
 
Old 07-02-2010, 05:54 AM
"Paweł Hajdan, Jr."
 
Default Over using preserve_old_lib, don't do that

On 7/2/10 7:51 AM, Samuli Suominen wrote:
> It's a hack, not a solution

Should we make repoman issue a warning about it?

It already warns about using make -j1 as a workaround for upstream
issues. The new warning could be on the same level (yellow, not red).

Paweł
 
Old 07-02-2010, 05:58 AM
Samuli Suominen
 
Default Over using preserve_old_lib, don't do that

On 07/02/2010 08:51 AM, Samuli Suominen wrote:
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
>
> Please only use the preserve_old_lib function in case of breaking:
>
> - base-system
> - toolchain
> - or the library is so widely used that revdep-rebuilding the system
> would be nearly impossible without having the old lib around since
> revdep-rebuild (emerge) can't get the emerge ordering right (because of
> overlinking and lack of asneeded by default, namely jpeg and png comes
> into mind)

Futhermore the old library gets injected to binpkgs as a file of the new
package, see recent bug:

http://bugs.gentoo.org/326275
http://bugs.gentoo.org/show_bug.cgi?id=326275#c7
 
Old 07-02-2010, 06:03 AM
Samuli Suominen
 
Default Over using preserve_old_lib, don't do that

On 07/02/2010 08:54 AM, "Paweł Hajdan, Jr." wrote:
> On 7/2/10 7:51 AM, Samuli Suominen wrote:
>> It's a hack, not a solution
>
> Should we make repoman issue a warning about it?
>
> It already warns about using make -j1 as a workaround for upstream
> issues. The new warning could be on the same level (yellow, not red).

That sounds good (and easily doable), small reminder doesn't hurt
 
Old 07-02-2010, 06:15 AM
Samuli Suominen
 
Default Over using preserve_old_lib, don't do that

On 07/02/2010 09:03 AM, Samuli Suominen wrote:
> On 07/02/2010 08:54 AM, "Paweł Hajdan, Jr." wrote:
>> On 7/2/10 7:51 AM, Samuli Suominen wrote:
>>> It's a hack, not a solution
>>
>> Should we make repoman issue a warning about it?
>>
>> It already warns about using make -j1 as a workaround for upstream
>> issues. The new warning could be on the same level (yellow, not red).
>
> That sounds good (and easily doable), small reminder doesn't hurt
>

https://bugs.gentoo.org/show_bug.cgi?id=326553
 
Old 07-02-2010, 06:08 PM
Mike Frysinger
 
Default Over using preserve_old_lib, don't do that

On Friday, July 02, 2010 01:51:25 Samuli Suominen wrote:
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_bug.cgi?id=326517#c5
>
> Please only use the preserve_old_lib function in case of breaking:
> - or the library is so widely used that revdep-rebuilding the system
> would be nearly impossible without having the old lib around since
> revdep-rebuild (emerge) can't get the emerge ordering right (because of
> overlinking and lack of asneeded by default, namely jpeg and png comes
> into mind)

i dont know how critical libgnomekbd is to the general running of GNOME, but
if all GNOME apps break because of it, then that is a valid use case.
upgrading a library that the whole desktop env cascades upon should not result
in the inability to log in (i.e. being forced to work in a Linux console shell
to recover things).

that bug report looks to me like the user not reading the output where they
have to delete the file themselves.
-mike
 
Old 07-05-2010, 04:40 PM
Gilles Dartiguelongue
 
Default Over using preserve_old_lib, don't do that

Le vendredi 02 juillet 2010 08:51 +0300, Samuli Suominen a crit :
> I've recently stumbled upon several packages unnecessarily using old
> preserve_old_lib feature from eutils.eclass, namely:
>
> libgnomekbd
> libproxy
>
> And then users hit issues like this:
>
> https://bugs.gentoo.org/show_bug.cgi?id=326517#c5

1. How is it different than preserved-libs feature from
portage-2.2 ? The issue that I have with you argument is that
you encourage breaking user apps at build time instead of
leaving the user some time to run revdep-rebuild or any other
tool needed when user wishes so.
2. We cannot (and do not in gnome herd) support users who did not
complete revdep-rebuild. We help them get out of build problem
if possible and if the bug still exists by then, we try to fix
it but otherwise it's just closed invalid.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo
 
Old 07-15-2010, 08:49 AM
Mike Auty
 
Default Over using preserve_old_lib, don't do that

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry I'm a bit late to the thread,

Just to add that empathy preserves libemapthy in this manner too.

On 05/07/10 17:40, Gilles Dartiguelongue wrote:
>
> 1. How is it different than preserved-libs feature from
> portage-2.2 ? The issue that I have with you argument is that
> you encourage breaking user apps at build time instead of
> leaving the user some time to run revdep-rebuild or any other
> tool needed when user wishes so.

This is different from preserve-libs because FEATURES="-preserve-libs"
doesn't stop these calls from keeping old libraries around. Also, once
preserve-libs has been used, a normal revdev-rebuild won't spot these
issues, and cruft-checkers can't find them because they're classed as
part of the new package.

I understand we have users who want this feature, and also that we
advise everybody to read through every single elog message ever made.
Having said that, I personally know how to run revdep-rebuild, and I do
it often so that when I'm upgrading 100+ packages in one go, I don't
then have to sit around reading through every elog message to make sure
that a library I didn't ask for doesn't accidentally get left on my
system for all time.

I can live with this for in places where it causes massive breakage
(openssl/libpng/libjpg), because it's genuinely useful, but I think it
should be restricted to such important packages, or at least disabled by
FEATURES="-preserve-libs".

Ideally, these calls should either adhere to FEATURES="-preserve-libs",
or there should be a tool that can identify which files portage has
preserved, and allow easy rebuilding of dependent packages, and removal.
At the moment, I'm having to manually grep ebuilds, ls the libraries
and run revdep-rebuild over them one at a time...

Mike 5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEARECAAYFAkw+y6oACgkQu7rWomwgFXoehQCgsrbUBRorY6 J4rBmASh16t1eP
YzoAnAhAi7kWd/bI9xhUh8UHMFfCR5xY
=OOj9
-----END PGP SIGNATURE-----
 
Old 07-15-2010, 09:09 AM
Gilles Dartiguelongue
 
Default Over using preserve_old_lib, don't do that

Le jeudi 15 juillet 2010 09:49 +0100, Mike Auty a crit :
[...]
> I can live with this for in places where it causes massive breakage
> (openssl/libpng/libjpg), because it's genuinely useful, but I think it
> should be restricted to such important packages, or at least disabled by
> FEATURES="-preserve-libs".
>
> Ideally, these calls should either adhere to FEATURES="-preserve-libs",
> or there should be a tool that can identify which files portage has
> preserved, and allow easy rebuilding of dependent packages, and removal.
> At the moment, I'm having to manually grep ebuilds, ls the libraries
> and run revdep-rebuild over them one at a time...

These sound like very good ideas to me.

--
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo
 
Old 07-15-2010, 10:14 AM
Duncan
 
Default Over using preserve_old_lib, don't do that

Gilles Dartiguelongue posted on Thu, 15 Jul 2010 11:09:39 +0200 as
excerpted:

> Le jeudi 15 juillet 2010 09:49 +0100, Mike Auty a crit : [...]
>> I can live with this for in places where it causes massive breakage
>> (openssl/libpng/libjpg), because it's genuinely useful, but I think it
>> should be restricted to such important packages, or at least disabled
>> by FEATURES="-preserve-libs".
>>
>> Ideally, these calls should either adhere to FEATURES="-preserve-libs",
>> or there should be a tool that can identify which files portage has
>> preserved, and allow easy rebuilding of dependent packages, and
>> removal.
>> At the moment, I'm having to manually grep ebuilds, ls the libraries
>> and run revdep-rebuild over them one at a time...
>
> These sound like very good ideas to me.

++

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.

--
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
 

Thread Tools




All times are GMT. The time now is 07:10 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org