Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?

2008-05-28 Thread Rémi Cardona

Marius Mauch a écrit :

So, do you think it should be enabled by default?


Does portage have a way to report which libraries it is keeping around 
because of preserve-libs ? If there's an easy way to figure that out, 
then enabling it by default is a very sane and sound idea.


Cheers,

Rémi
--
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] RFC: Should preserve-libs be enabled by default?

2008-05-28 Thread Donnie Berkholz
On 01:13 Thu 29 May , Marius Mauch wrote:
> One concern raised by some people is that it might cause old libraries
> with security issues to stay on the system for eternity even though
> the package was upgraded, and eventually be preferred by new builds.
> I can't rule this out completely but thinks it's very unlikely, as
> preserved libraries are specially tracked and the user is notified
> about their existance after every emerge operation (similar to glep42
> news).

Part of this should be addressable by keeping track of the version that 
installed them and checking it against the distributed GLSAs...

Thanks,
Donnie
-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Re: RFC: Should preserve-libs be enabled by default?

2008-05-28 Thread Ryan Hill
On Thu, 29 May 2008 01:13:16 +0200
Marius Mauch <[EMAIL PROTECTED]> wrote:

> So, do you think it should be enabled by default?

Yes please. :)  I haven't had any problems in the couple of months
i've been using it.


-- 
fonts, gcc-porting,   by design, by neglect
mips, treecleaner,for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature


[gentoo-dev] RFC: Should preserve-libs be enabled by default?

2008-05-28 Thread Marius Mauch
As portage-2.2 is about to be unmasked into ~arch soon (there is one
weird bug to solve before) it's time to ask for some input on one of
the important new features, FEATURES=preserve-libs.

(if you're already familiar with it you can skip this paragraph)
Simply said, when this feature is enabled portage keeps track of all
installed libraries and binaries linked against them, and if a package
upgrade would remove a library that's still in use portage will keep
the library around, owned by the new version and also registered in a
separate file. There is also an internal package set that can be used
to rebuild all packages linked against libraries preserved in this way,
and the user is notified after each emerge operation that he should do
that (the example is from an expat downgrade in case you wonder about
the versions): 
!!! existing preserved libs:
>>> package: dev-libs/expat-1.95.8
 *  - /usr/lib64/libexpat.so.1
 *  - /usr/lib64/libexpat.so.1.5.2
Use emerge @preserved-rebuild to rebuild packages using these libraries

The purpose of this is to keep the system operational after library
upgrades until all affected packages could be rebuilt and to simplify
the process, not to avoid the rebuilds.

Now the question is if this behavior should be enabled by default?

In the existing prereleases it has been enabled to get some real-world
testing, and it's been quite effective, though there are still a few
issues to be worked out (e.g. if libraries are moved between packages).
And no doubt a few more bugs will turn up over time.
Also it is not going to be a perfect solution against all runtime link
errors, but if enabled it should eliminate the need for revdep-rebuild
in most cases.
One concern raised by some people is that it might cause old libraries
with security issues to stay on the system for eternity even though
the package was upgraded, and eventually be preferred by new builds.
I can't rule this out completely but thinks it's very unlikely, as
preserved libraries are specially tracked and the user is notified
about their existance after every emerge operation (similar to glep42
news). And new builds shouldn't find them as the unversioned .so
symlinks ar going to point to the current versions.
So personally I'm not too worried about this concern becoming reality,
but I can understand if others are.

So, do you think it should be enabled by default?

Marius

PS: Obviously, if you haven't tested portage-2.2 yet, now would be a
good time.

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2008-05-28 Thread Thomas Anderson
On Wed, May 28, 2008 at 09:03:33AM +0200, Krzysiek Pawlik wrote:
>  * net-im/jabberd & net-im/jabberd2 - thanks to work from Marko Durkovic 
> both are easy to maintain
I can take jabberd(maybe jabberd2 too) by proxy, until I finish my
quizzes.


-- 
gentoo-dev@lists.gentoo.org mailing list



[gentoo-dev] Packages up for grabs

2008-05-28 Thread Krzysiek Pawlik


There are few packages that could use some more loving:

 * app-editors/scite - easy to maintain, has only one bug open wrt French 
locales & UTF-8

 * media-video/griffith - also easy, pending version bump
 * net-im/jabberd & net-im/jabberd2 - thanks to work from Marko Durkovic both 
are easy to maintain


--
Krzysiek Pawlik  key id: 0xBC51
desktop-misc, java, apache, ppc, vim, kernel, python...



signature.asc
Description: OpenPGP digital signature