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 06-28-2011, 08:48 AM
Michał Górny
 
Default ldconfig symlink updates -- do we need that?

Hello,

As you may or may not know, right now env-update calls 'ldconfig'
by default, describing that in the terms of 'Regenerating
/etc/ld.so.cache'. In fact, it does a little more -- it updates library
symlinks to use the newest library version available.

In other words, if we've got libfoo.so.1.1 and .1.2 with the same
SONAME, and libfoo.so.1 symlinks to .1.1, ldconfig would replace that
by a symlink to .1.2.

This seems to be the major cause of the problems with portage's
preserve-libs feature. When a package is downgraded, portage replaces
the SONAME symlink with an older version to make newly-built packages
use that older version, and preserves the newer libraries not to break
linkage.

But a short while later, ldconfig takes over the symlink and makes it
point to the newer version once again. Packages still link to the newer
version and the only way to get the library actually downgraded is to
remove the preserved library. Thus, it's even worse than without
preserved-libs.

On the other hand, that ldconfig behavior seems completely redundant
as packages are installed with .so symlinks anyway. And I think that if
package manager installs those symlinks, it should manage them itself
instead of letting external tools mangle with PM-installed files.

I have created a patch which makes 'env-update' always pass '-X' to
ldconfig, to not let it update the symlinks in system-wide libdirs. I'm
testing it right now to see if it doesn't cause any breakage.

If that causes problems (i.e. some packages don't actually create
correct .so symlinks themselves), I guess we could decide to call
'ldconfig -N -n' in post-install operations, like the deprecated
'preplib' helper does.

This way, the symlinks will be completely controlled by the Package
Manager and the preserve-libs feature should handle downgrades just
fine.

And I've just downgraded libav, and rebuilt mplayer2 against it with
the newer version being preserved just fine.

--
Best regards,
Michał Górny
 
Old 06-28-2011, 08:53 AM
Michał Górny
 
Default ldconfig symlink updates -- do we need that?

On Tue, 28 Jun 2011 10:48:48 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> I have created a patch which makes 'env-update' always pass '-X' to
> ldconfig, to not let it update the symlinks in system-wide libdirs.
> I'm testing it right now to see if it doesn't cause any breakage.

And, as always, forgot to attach it. Here it goes.

--
Best regards,
Michał Górny
 
Old 06-28-2011, 03:31 PM
Cyprien Nicolas
 
Default ldconfig symlink updates -- do we need that?

On 28/06/11 10:53, Michał Górny wrote:
> On Tue, 28 Jun 2011 10:48:48 +0200 Michał Górny <mgorny@gentoo.org>
> wrote:

I'm a noob in Python, but I disagree with this patch. for two reasons:

First, the -X option is already available, and controlled by makelinks,
so why not change the default value of makelinks to False?

Second, after trying to understand the code, if your proposed patch is
applied, the makelinks variable become useless. So why not remove it
completly from the source? Is this variable still needed?

There is some bunch of code starting at line 222 in the current HEAD,
which sets makelinks to False upon some conditions, does this need to be
refactored / removed somehow too?

--
Cyprien Nicolas (fulax)
Lisp project contributor
 
Old 06-28-2011, 03:43 PM
Michał Górny
 
Default ldconfig symlink updates -- do we need that?

On Tue, 28 Jun 2011 17:31:11 +0200
Cyprien Nicolas <c.nicolas@gmail.com> wrote:

> On 28/06/11 10:53, Michał Górny wrote:
> > On Tue, 28 Jun 2011 10:48:48 +0200 Michał Górny <mgorny@gentoo.org>
> > wrote:
>
> I'm a noob in Python, but I disagree with this patch. for two reasons:
>
> First, the -X option is already available, and controlled by
> makelinks, so why not change the default value of makelinks to False?
>
> Second, after trying to understand the code, if your proposed patch is
> applied, the makelinks variable become useless. So why not remove it
> completly from the source? Is this variable still needed?
>
> There is some bunch of code starting at line 222 in the current HEAD,
> which sets makelinks to False upon some conditions, does this need to
> be refactored / removed somehow too?

This patch is just the simplest approach to see if it works as
expected. We'll prepare a better/more consistent patch when the concept
itself is accepted.

--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 06:48 PM.

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