[gentoo-dev] Dangerous features in portage

[gentoo-dev] Dangerous features in portage

[Kim Nielsen]

I just found a rather dangerous feature in portage. After doing an
emerge -u world it automaticly did an emerge clean (Which I heard was
Gentoo policy now)

This is plain stupid and dangerous since I'm now missing several shared
objects (.so files). In order to correct it I have two choices

1. emerge -e world
or
2. emerge -e <broken packages>

which will take alot of time.

Why has this become a features ? did anyone not consider the
consequences it could have ?

/Kim

Re: [gentoo-dev] Dangerous features in portage

[Sven Vermeulen]

On 29 Oct 2002, Kim Nielsen wrote:

> I just found a rather dangerous feature in portage. After doing an
> emerge -u world it automaticly did an emerge clean (Which I heard was
> Gentoo policy now)
>
> This is plain stupid and dangerous since I'm now missing several shared
> objects (.so files). In order to correct it I have two choices

emerge clean doesn't do anything to your system, it only removes
ebuild-files from _your_ portage-tree that aren't available anymore on the
rsync-server(s) (and thus aren't really in Gentoo anymore).

Your missing .so-files have an other cause...

	Sven Vermeulen

-- 
 I thought I saw a pussycat...
 I did! I did! I did saw a pussycat!
 			(Tweety)

Re: [gentoo-dev] Dangerous features in portage

[Markus Wagner]

Hi!

On Tuesday 29 October 2002 10:06, Sven Vermeulen wrote:
> emerge clean doesn't do anything to your system, it only removes
> ebuild-files from _your_ portage-tree that aren't available anymore on
> the rsync-server(s) (and thus aren't really in Gentoo anymore).

Not at all. From "man emerge":

clean (-c) 
Cleans the system by removing packages that will not effect the 
functionality of the system. The arguments can be ebuilds, classes, or 
dependencies. For example, emerge clean binutils cleans out old versions 
of binutils; emerge clean net-www/mozilla-0.9.9-r2 cleans out that 
specific version of Mozilla. This is generally safe to use. Note that 
clean does not remove unslotted packages.

So if there are foobar-1.0 and foobar-1.1 installed and they are in the 
same slot, "emerge clean" will safely unmerge foobar-1.0.

> Your missing .so-files have an other cause...

ACK.

Markus
-- 
"We can debug relationships, but it's always good policy to
consider the people themselves to be features. People get annoyed 
when you try to debug them." ( Larry Wall )

Re: [gentoo-dev] Dangerous features in portage

[cycloon]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Tue, 2002-10-29 at 10:21, Markus Wagner wrote:
> Hi!
> 
> On Tuesday 29 October 2002 10:06, Sven Vermeulen wrote:
> > emerge clean doesn't do anything to your system, it only removes
> > ebuild-files from _your_ portage-tree that aren't available anymore on
> > the rsync-server(s) (and thus aren't really in Gentoo anymore).

I think this is why they made it default, if you clean out those old
packages imediately you wont get into trouble when cleaning out the
system after some month of updates

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Dangerous features in portage

[Kim Nielsen]

On Tue, 2002-10-29 at 10:06, Sven Vermeulen wrote:
> 
> Your missing .so-files have an other cause...

No.

Some files are linked to a lot of .so files .. when one files gets
renewed it gets new features and version .. when the old program is
linked to this version you don't automaticly emerge evolution for
example . You just upgrade the lib that its using. And that is the
problem I'm having.

Otherwise you would have to remerge galeon everytime you mozilla ..
haven't you ever seen that error/message that galeon says if its linked
against an old version of mozilla ?

/Kim

Re: [gentoo-dev] Dangerous features in portage

[Paul de Vrieze]

On Tuesday 29 October 2002 11:38, Kim Nielsen wrote:
> On Tue, 2002-10-29 at 10:06, Sven Vermeulen wrote:
> > Your missing .so-files have an other cause...
>
> No.
>
> Some files are linked to a lot of .so files .. when one files gets
> renewed it gets new features and version .. when the old program is
> linked to this version you don't automaticly emerge evolution for
> example . You just upgrade the lib that its using. And that is the
> problem I'm having.
>
> Otherwise you would have to remerge galeon everytime you mozilla ..
> haven't you ever seen that error/message that galeon says if its linked
> against an old version of mozilla ?
>
> /Kim

The problem is downgrading. If you have had installed say libfoo-1.1. Now the 
developers find out that libfoo-1.1 is seriously broken. As a consequence, 
libfoo-1.1 is masked, and libfoo-1.0 is the newest. If you now do an emerge 
-u libfoo the old version is installed. But if libfoo-1.0 allready was 
installed it doesn't get installed. The installation of libfoo-1.0 is not 
complete though, because libfoo-1.1 overwrites many of its files. Now with an 
emerge clean libfoo-1.1 is removed, as a consequence libfoo-1.0 is crippled 
and libfoo-1.1 is removed. An emerge clean after the upgrade to libfoo-1.1 
would have stopped this. This is so the reason that emerge now performs an 
autoclean.

Paul

-- 
Paul de Vrieze
Junior Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.cs.kun.nl/~pauldv

Re: [gentoo-dev] Dangerous features in portage

[Jean-Michel Smith]

On Tuesday 29 October 2002 07:23 am, Paul de Vrieze wrote:

> The problem is downgrading. If you have had installed say libfoo-1.1. Now
> the developers find out that libfoo-1.1 is seriously broken. As a
> consequence, libfoo-1.1 is masked, and libfoo-1.0 is the newest. If you now
> do an emerge -u libfoo the old version is installed. But if libfoo-1.0
> allready was installed it doesn't get installed. The installation of
> libfoo-1.0 is not complete though, because libfoo-1.1 overwrites many of
> its files. Now with an emerge clean libfoo-1.1 is removed, as a consequence
> libfoo-1.0 is crippled and libfoo-1.1 is removed. An emerge clean after the
> upgrade to libfoo-1.1 would have stopped this. This is so the reason that
> emerge now performs an autoclean.

What about situations where you want to keep multiple versions of a shared 
library (that is, after all, one of the nice features of UNIX over, say, 
Windows)?  For example, you may have software that is compiled against an 
older, incompatible version of imlib (or worse, 3rd party binaries you can't 
recompile).

emerge clean nukes the old installation, and while the system is now no longer 
crufty it is also incompatible with that application.  I've seen this kino 
(before the new version came out) and dvlib, for example, and I'm sure there 
are other situations as well.

Jean.

Re: [gentoo-dev] Dangerous features in portage

[Jonathan Hunt]

On Thu, 31 Oct 2002 8:11 am, Jean-Michel Smith wrote:
> On Tuesday 29 October 2002 07:23 am, Paul de Vrieze wrote:
> > The problem is downgrading. If you have had installed say libfoo-1.1. Now
> > the developers find out that libfoo-1.1 is seriously broken. As a
> > consequence, libfoo-1.1 is masked, and libfoo-1.0 is the newest. If you
> > now do an emerge -u libfoo the old version is installed. But if
> > libfoo-1.0 allready was installed it doesn't get installed. The
> > installation of libfoo-1.0 is not complete though, because libfoo-1.1
> > overwrites many of its files. Now with an emerge clean libfoo-1.1 is
> > removed, as a consequence libfoo-1.0 is crippled and libfoo-1.1 is
> > removed. An emerge clean after the upgrade to libfoo-1.1 would have
> > stopped this. This is so the reason that emerge now performs an
> > autoclean.
>
> What about situations where you want to keep multiple versions of a shared
> library (that is, after all, one of the nice features of UNIX over, say,
> Windows)?  For example, you may have software that is compiled against an
> older, incompatible version of imlib (or worse, 3rd party binaries you
> can't recompile).
>
> emerge clean nukes the old installation, and while the system is now no
> longer crufty it is also incompatible with that application.  I've seen
> this kino (before the new version came out) and dvlib, for example, and I'm
> sure there are other situations as well.
>
> Jean.

Isn't that what slots are for?

-- 
Jonathan Hunt (The Real Jonathan Hunt) <jhuntnz@users.sourceforge.net>
Jabber at jhuntnz@jabber.sk
"He is no fool who gives what he cannot keep to gain what he cannot lose."
Jim Elliot

[gentoo-dev] Re: Dangerous features in portage

[Paul]

Jean-Michel Smith <jsmith@kcco.com>, on Wed Oct 30, 2002 [01:11:10 PM] said:
> 
> What about situations where you want to keep multiple versions of a shared 
> library (that is, after all, one of the nice features of UNIX over, say, 
> Windows)?  For example, you may have software that is compiled against an 
> older, incompatible version of imlib (or worse, 3rd party binaries you can't 
> recompile).
> 
> emerge clean nukes the old installation, and while the system is now no longer 
> crufty it is also incompatible with that application.  I've seen this kino 
> (before the new version came out) and dvlib, for example, and I'm sure there 
> are other situations as well.
> 
> Jean.

	Hi;

	I believe the SLOT ebuild variable is for just this
situation.  I personally have quite a few packages where old and
new libraries coexist, and 'emerge clean' leaves them alone.
	'emerge prune' will nuke all but the latest version
of a package, I believe. (and perhaps older stuff that was
unSLOTed.)
	So, I would consider it a bug if 'clean' nuked an old
version of a package that can coexist with newer versions via
a SLOT...

Paul
set@pobox.com

Re: [gentoo-dev] Dangerous features in portage

[Wilbert Berendsen]

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

On Wednesday 30 October 2002 20:21, Jonathan Hunt wrote:
> > What about situations where you want to keep multiple versions of a
> > shared library (that is, after all, one of the nice features of UNIX
> > over, say, Windows)?  For example, you may have software that is compiled
> > against an older, incompatible version of imlib (or worse, 3rd party
> > binaries you can't recompile).
> >
> > emerge clean nukes the old installation, and while the system is now no
> > longer crufty it is also incompatible with that application.  I've seen
> > this kino (before the new version came out) and dvlib, for example, and
> > I'm sure there are other situations as well.
> >
> > Jean.
>
> Isn't that what slots are for?

Yes, but not all upgrades have a different slot. Here at one time aspell got 
upgraded. Thereafter sylpheed-claws wouldn't work. It appeared 
libaspell-so.50.1 or so got replaced by a 50.2 version. I had to remerge 
sylpheed-claws.

Groet,
Wilbert

- -- 
Wilbert Berendsen (http://www.xs4all.nl/~wbsoft/)
To understand recursion, one must first understand recursion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9wUT8x+vk367Vl7wRAvtdAKC1GHa78vXqeTIpRUtv5PhU9ZBl0ACdElZW
T3gX6BlHSjNHArTafD/nSTY=
=Gzu7
-----END PGP SIGNATURE-----