[gentoo-amd64] libungif and giflib conflict.

[gentoo-amd64] libungif and giflib conflict.

[Nick Currier]

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

Here is what I am getting.

[blocks B ] media-libs/libungif (is blocking media-libs/giflib-4.1.4)

When trying to emerge -uaDv world to get my system up to date.

I have an ~amd64 xorg but I don't think that has anything to do with my
problem. This was necessary to get rid of my blacked out OO-2.0 icons which
was just mostly an annoyance. Also, I don't have USE=gif under my
/etc/make.conf file anymore and I still seem to be having this problem. I
have to run libungif as all my media is built around mplayer and it simply
won't run on the giflib libraries. This just popped up within the last two
days worth of --sync. I have even tried to rebuild using NEWUSE but even
that seems to give me the blocked package issue.

Strangeness. I know I could probably add media-libs/giflib to my blocked
packages list but this seems like a band-aid fix and I would like to find
the root (no pun intended) of my problem.

Thanks for any help.
Nick

[-- Attachment #2: Type: text/html, Size: 1070 bytes --]

Re: [gentoo-amd64] libungif and giflib conflict.

[Barry.SCHWARTZ]

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

Nick Currier <docfreezzzz@gmail.com> writes:
> I have to run libungif as all my media is built around mplayer and it simply
> won't run on the giflib libraries.

My mplayer is linked with giflib and AFAIK it works as it should. I
suspect you need to run revdep-rebuild.

Otherwise I would try installing libungif in /usr/local, the
old-fashioned way, and put an entry in package.provided or something
like that.

-- 
Barry.SCHWARTZ@chemoelectric.org   http://www.chemoelectric.org
Esperantistoj rajtas skribi al Barijo.SXVARCO@chemoelectric.org
   'And now we're going to go try to comfort people in that
 part of the world.' -- Bush, referring to the southeastern U.S.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] libungif and giflib conflict.

[Brian Litzinger]

> Nick Currier <docfreezzzz@gmail.com> writes:
> > I have to run libungif as all my media is built around mplayer and it simply
> > won't run on the giflib libraries.

On Mon, Oct 31, 2005 at 11:52:03PM -0600, Barry.SCHWARTZ@chemoelectric.org wrote:
> My mplayer is linked with giflib and AFAIK it works as it should. I
> suspect you need to run revdep-rebuild.
> Otherwise I would try installing libungif in /usr/local, the
> old-fashioned way, and put an entry in package.provided or something
> like that.

I had cross dependecies between mplayer and another app.

One required giflib the other libungif.

After getting tired of emerging back and forth I did

(unmerged the other lib)

emerge giflib
cd /usr/lib
ln -s libgif.so.4.1.3 libungif.so.4 

All is better now.

-- 
Brian Litzinger
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: libungif and giflib conflict.

[Duncan]

Brian Litzinger posted <20051101060037.GA30285@localhost>, excerpted
below,  on Mon, 31 Oct 2005 22:00:37 -0800:

>> Nick Currier <docfreezzzz@gmail.com> writes:
>> > I have to run libungif as all my media is built around mplayer and it
>> > simply won't run on the giflib libraries.
> 
> On Mon, Oct 31, 2005 at 11:52:03PM -0600, Barry.SCHWARTZ@chemoelectric.org
> wrote:
>> My mplayer is linked with giflib and AFAIK it works as it should. I
>> suspect you need to run revdep-rebuild. Otherwise I would try installing
>> libungif in /usr/local, the old-fashioned way, and put an entry in
>> package.provided or something like that.
> 
> I had cross dependecies between mplayer and another app.
> 
> One required giflib the other libungif.
> 
> After getting tired of emerging back and forth I did
> 
> (unmerged the other lib)
> 
> emerge giflib
> cd /usr/lib
> ln -s libgif.so.4.1.3 libungif.so.4

That works, but it's an unneeded hack.

Here's the history behind libgif/libungif.  Unisys apparently had a patent
on the compression method normally used in gif.  They let gif format
graphics become rather a standard, and then started demanding royalties
for the compression patent.  Of course, royalties aren't something very
compatible with open source, so that didn't work too well.

There were two responses among both the open source community and the web
community (which used both gif and jpeg).  One was to develop an
uncompromised standard, the PING graphic standard, and switch to using it
on most web pages and the like. (This was complicated by the fact that
MSIE didn't properly support PING for a long time.)

The other, as we have here, was to work with a library that used the same
standard but without the compression.  Apparently, it was possible to read
compressed gifs without violating the patent, but it wasn't possible to
create or do graphics work in the format, at least not and compress it. 
Thus, libungif was born, using the workaround to decompress gifs, but when
used to work with gifs, it would store them uncompressed.

The patents apparently expired between 2001 and late 2003, depending on
the location, so gifs can now use the normal compression without issue,
and there's little use for libungif any longer.

According to a discussion some weeks/months ago on gentoo-dev, Gentoo is
deprecating libungif, and will eventually remove it from the tree. 
Apparently, new versions of everything that could depend on either is now
set to depend on libgif only.  After a suitable length of time, or when
it becomes difficult to support libungif any longer (I don't believe
there's anything being done with it upstream any longer), it will be
removed from the tree.

So... no new ebuilds should depend on libungif.  If they do, it's a bug
and probably should be filed as such.

Meanwhile, existing ebuilds, particularly as currently merged, may still
depend on libungif.  However, most  of them should work just fine if
rebuilt against libgif.  Unmerge libungif (and remove that symlink you
created) so there's no libungif on the system.  Then ensure you have a
current libgif merged and do a revdep-rebuild -p to see what is detected
as needing remerged. Then go ahead and do the remerge of those packages,
either by running the command without the -p, or by emerging the
individual packages by name.

Nothing should need to pull in libungif.  It's still possible that some
old stable packages might want it.  However, sticking those in
package.keyword with ~amd64 should result in a newer package that merges
fine without libungif.  If it's still required, then it's time to file a
bug (check first, of course, to see if there's already been one filed on
it).

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: libungif and giflib conflict.

[Nick Currier]

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

Thanks guys. Really appreciate the help. Will try ~amd64 for mplayer.

NIck Currier

On 11/1/05, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Brian Litzinger posted <20051101060037.GA30285@localhost>, excerpted
> below, on Mon, 31 Oct 2005 22:00:37 -0800:
>
> >> Nick Currier <docfreezzzz@gmail.com> writes:
> >> > I have to run libungif as all my media is built around mplayer and it
> >> > simply won't run on the giflib libraries.
> >
> > On Mon, Oct 31, 2005 at 11:52:03PM -0600,
> Barry.SCHWARTZ@chemoelectric.org
> > wrote:
> >> My mplayer is linked with giflib and AFAIK it works as it should. I
> >> suspect you need to run revdep-rebuild. Otherwise I would try
> installing
> >> libungif in /usr/local, the old-fashioned way, and put an entry in
> >> package.provided or something like that.
> >
> > I had cross dependecies between mplayer and another app.
> >
> > One required giflib the other libungif.
> >
> > After getting tired of emerging back and forth I did
> >
> > (unmerged the other lib)
> >
> > emerge giflib
> > cd /usr/lib
> > ln -s libgif.so.4.1.3 libungif.so.4
>
> That works, but it's an unneeded hack.
>
> Here's the history behind libgif/libungif. Unisys apparently had a patent
> on the compression method normally used in gif. They let gif format
> graphics become rather a standard, and then started demanding royalties
> for the compression patent. Of course, royalties aren't something very
> compatible with open source, so that didn't work too well.
>
> There were two responses among both the open source community and the web
> community (which used both gif and jpeg). One was to develop an
> uncompromised standard, the PING graphic standard, and switch to using it
> on most web pages and the like. (This was complicated by the fact that
> MSIE didn't properly support PING for a long time.)
>
> The other, as we have here, was to work with a library that used the same
> standard but without the compression. Apparently, it was possible to read
> compressed gifs without violating the patent, but it wasn't possible to
> create or do graphics work in the format, at least not and compress it.
> Thus, libungif was born, using the workaround to decompress gifs, but when
> used to work with gifs, it would store them uncompressed.
>
> The patents apparently expired between 2001 and late 2003, depending on
> the location, so gifs can now use the normal compression without issue,
> and there's little use for libungif any longer.
>
> According to a discussion some weeks/months ago on gentoo-dev, Gentoo is
> deprecating libungif, and will eventually remove it from the tree.
> Apparently, new versions of everything that could depend on either is now
> set to depend on libgif only. After a suitable length of time, or when
> it becomes difficult to support libungif any longer (I don't believe
> there's anything being done with it upstream any longer), it will be
> removed from the tree.
>
> So... no new ebuilds should depend on libungif. If they do, it's a bug
> and probably should be filed as such.
>
> Meanwhile, existing ebuilds, particularly as currently merged, may still
> depend on libungif. However, most of them should work just fine if
> rebuilt against libgif. Unmerge libungif (and remove that symlink you
> created) so there's no libungif on the system. Then ensure you have a
> current libgif merged and do a revdep-rebuild -p to see what is detected
> as needing remerged. Then go ahead and do the remerge of those packages,
> either by running the command without the -p, or by emerging the
> individual packages by name.
>
> Nothing should need to pull in libungif. It's still possible that some
> old stable packages might want it. However, sticking those in
> package.keyword with ~amd64 should result in a newer package that merges
> fine without libungif. If it's still required, then it's time to file a
> bug (check first, of course, to see if there's already been one filed on
> it).
>
> --
> 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 in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
>
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 5215 bytes --]

Re: [gentoo-amd64] Re: libungif and giflib conflict.

[Brian Litzinger]

> > (unmerged the other lib)
> > 
> > emerge giflib
> > cd /usr/lib
> > ln -s libgif.so.4.1.3 libungif.so.4

On Tue, Nov 01, 2005 at 01:36:23AM -0700, Duncan wrote:
> That works, but it's an unneeded hack.

> Nothing should need to pull in libungif.  It's still possible that some
> old stable packages might want it.  However, sticking those in
> package.keyword with ~amd64 should result in a newer package that merges
> fine without libungif.  If it's still required, then it's time to file a
> bug (check first, of course, to see if there's already been one filed on
> it).

grep amd64 /etc/make.conf

ACCEPT_KEYWORDS="~amd64"

Been ~amd64 since the day I got this laptop.

The last time I hit the problem was on 

lrwxrwxrwx  1 root root 15 Oct 21 14:43 /usr/lib/libungif.so.4 ->
libgif.so.4.1.3

when I finally got tired and created the link.

Thus on Oct 21st at 13:43 (PST) you could still experience the
problem as a ~amd64 type.

I got slapped in the face as a small child for filing a duplicate
bug.  Thus I am, as an adult, unable to file bugs. :(
 
-- 
Brian Litzinger
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: libungif and giflib conflict.

[Duncan]

Brian Litzinger posted <20051101173928.GA13381@localhost>, excerpted
below,  on Tue, 01 Nov 2005 09:39:29 -0800:

> Been ~amd64 since the day I got this laptop.
> 
> The last time I hit the problem was on 
> 
> lrwxrwxrwx  1 root root 15 Oct 21 14:43 /usr/lib/libungif.so.4 ->
> libgif.so.4.1.3
> 
> when I finally got tired and created the link.
> 
> Thus on Oct 21st at 13:43 (PST) you could still experience the
> problem as a ~amd64 type.
> 
> I got slapped in the face as a small child for filing a duplicate
> bug.  Thus I am, as an adult, unable to file bugs. :(

Did you do what I and others have suggested, a revdep-rebuild?  Note that
existing packages on your system may still be linked against the old
library.  Once it's in their binaries...

revdep-rebuild (as with anything portage related, run it with the -p the
first time thru to see what it's going to do) is designed to scan your
existing binaries to see what they need, and your existing library path
(that ld uses to find the libs it needs) to see what's provided.  Then it
makes a list of all the binaries (both executables, and libs that load
other libs) that have unfilled dependencies using the existing libraries,
traces down the packages they belong to, and remerges them (or with -p,
displays what it would merge), the intent being to recompile and relink
anything that's missing dependencies, either linking against new or
alternate versions of same, or pulling in the required dependencies to
merge as well.

Of course, this only works once that library has gone missing.  If you run
revdep-rebuild with the library (or a symlink pointing to an alternate)
still there, it'll think everything is fine and not list the package
owning the library in question for remerge.

Decently updated packages that formerly linked against libungif should now
link against libgif without difficulty.  However, with existing package on
the system linked against libungif, it's only to be expected that said
binaries would have issues.  The easiest way to fix them is to run
revdep-rebuild.  In fact, revdep-rebuild, along with emerge --newuse
--update --deep world, should be a regular part of the routine to keep a
well maintained and upto date system.  

(Another part of the same routine should be emerge depclean, but be sure
the revdep-rebuild and emerge --newuse are completed first, and check the
output of a --pretend depclean for stuff you know you want to keep around,
before letting it do its thing.  Then run revdep-rebuild again afterward,
just to be sure.)

These apply to some degree to everyone, but a bit less to slower moving
stable, than to faster moving ~arch.  Since ~arch may merge three versions
for every version that goes stable, including beta and rc versions on
occasion, cruft tends to buildup rather faster than it will on a stable
system.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: libungif and giflib conflict.

[Nick Currier]

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

Looks like that got it guys. Thanks tons for the help.... It seems I broke
portage by running only part ~amd64 packages. revdep-rebuild found it but it
took twice to fix..... depclean wants to get rid of tons of stuff though so
I'm thinking this is a bad idea or I have bigger problems.... Kudos to AMD64
Gentoo for the best support team in open source.

Nick

On 11/1/05, Duncan <1i5t5.duncan@cox.net> wrote:
>
> Brian Litzinger posted <20051101173928.GA13381@localhost>, excerpted
> below, on Tue, 01 Nov 2005 09:39:29 -0800:
>
> > Been ~amd64 since the day I got this laptop.
> >
> > The last time I hit the problem was on
> >
> > lrwxrwxrwx 1 root root 15 Oct 21 14:43 /usr/lib/libungif.so.4 ->
> > libgif.so.4.1.3
> >
> > when I finally got tired and created the link.
> >
> > Thus on Oct 21st at 13:43 (PST) you could still experience the
> > problem as a ~amd64 type.
> >
> > I got slapped in the face as a small child for filing a duplicate
> > bug. Thus I am, as an adult, unable to file bugs. :(
>
> Did you do what I and others have suggested, a revdep-rebuild? Note that
> existing packages on your system may still be linked against the old
> library. Once it's in their binaries...
>
> revdep-rebuild (as with anything portage related, run it with the -p the
> first time thru to see what it's going to do) is designed to scan your
> existing binaries to see what they need, and your existing library path
> (that ld uses to find the libs it needs) to see what's provided. Then it
> makes a list of all the binaries (both executables, and libs that load
> other libs) that have unfilled dependencies using the existing libraries,
> traces down the packages they belong to, and remerges them (or with -p,
> displays what it would merge), the intent being to recompile and relink
> anything that's missing dependencies, either linking against new or
> alternate versions of same, or pulling in the required dependencies to
> merge as well.
>
> Of course, this only works once that library has gone missing. If you run
> revdep-rebuild with the library (or a symlink pointing to an alternate)
> still there, it'll think everything is fine and not list the package
> owning the library in question for remerge.
>
> Decently updated packages that formerly linked against libungif should now
> link against libgif without difficulty. However, with existing package on
> the system linked against libungif, it's only to be expected that said
> binaries would have issues. The easiest way to fix them is to run
> revdep-rebuild. In fact, revdep-rebuild, along with emerge --newuse
> --update --deep world, should be a regular part of the routine to keep a
> well maintained and upto date system.
>
> (Another part of the same routine should be emerge depclean, but be sure
> the revdep-rebuild and emerge --newuse are completed first, and check the
> output of a --pretend depclean for stuff you know you want to keep around,
> before letting it do its thing. Then run revdep-rebuild again afterward,
> just to be sure.)
>
> These apply to some degree to everyone, but a bit less to slower moving
> stable, than to faster moving ~arch. Since ~arch may merge three versions
> for every version that goes stable, including beta and rc versions on
> occasion, cruft tends to buildup rather faster than it will on a stable
> system.
>
> --
> 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 in
> http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html
>
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 4393 bytes --]

Re: [gentoo-amd64] Re: Re: libungif and giflib conflict.

[Harm Geerts]

On Wednesday 02 November 2005 05:30, Nick Currier wrote:
> Looks like that got it guys. Thanks tons for the help.... It seems I broke
> portage by running only part ~amd64 packages. revdep-rebuild found it but
> it took twice to fix..... depclean wants to get rid of tons of stuff though
> so I'm thinking this is a bad idea or I have bigger problems.... Kudos to
> AMD64 Gentoo for the best support team in open source.

It's normal for a system that hasn't been maintained the way it should ;)
1. Look over the list of packages that would be unmerged with:
# emerge --pretend depclean
2. Inject the packages that should not be removed in your world file with:
# emerge --noreplace <package name>

Repeats steps 1 and 2 untill you are satisfied.
3. clean the remaining packages with:
# emerge --ask depclean
4. rebuild packages that were built against older/removed libaries:
# revdep-rebuild --pretend (part of app-portage/gentoolkit)

In order to keep your system clean in the future upgrade world like this:
1. upgrade your world, remerge packages that have a changed USE flag and 
upgrade deep dependencies.
# emerge --ask --deep --newuse --upgrade world
2. rebuild packages that were built against older/removed libaries
# revdep-rebuild --pretend

If you ever remove a package do it like this:
1. remove the package
# emerge --ask --unmerge package
2. remove the dependencies but always check the output. other packages might 
use them even though they are not a direct dependency
# emerge --ask depclean
3. rebuild packages that were build against libaries you just removed
# revdep-rebuild --pretend

This is how I maintain all my systems.
If anyone has remarks/tips I'd be glad to hear them.
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: libungif and giflib conflict.

[Nick Currier]

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

Okay... Now I know. Not used to this whole build from source concept yet but
I am getting much better at it. I cleaned up everything and now have no more
broken dependencies. Apparently I've just never emerge --depclean. Again
Kudos for all the help.

Nick

On 11/2/05, Harm Geerts <harmgeerts@home.nl> wrote:
>
> On Wednesday 02 November 2005 05:30, Nick Currier wrote:
> > Looks like that got it guys. Thanks tons for the help.... It seems I
> broke
> > portage by running only part ~amd64 packages. revdep-rebuild found it
> but
> > it took twice to fix..... depclean wants to get rid of tons of stuff
> though
> > so I'm thinking this is a bad idea or I have bigger problems.... Kudos
> to
> > AMD64 Gentoo for the best support team in open source.
>
> It's normal for a system that hasn't been maintained the way it should ;)
> 1. Look over the list of packages that would be unmerged with:
> # emerge --pretend depclean
> 2. Inject the packages that should not be removed in your world file with:
> # emerge --noreplace <package name>
>
> Repeats steps 1 and 2 untill you are satisfied.
> 3. clean the remaining packages with:
> # emerge --ask depclean
> 4. rebuild packages that were built against older/removed libaries:
> # revdep-rebuild --pretend (part of app-portage/gentoolkit)
>
> In order to keep your system clean in the future upgrade world like this:
> 1. upgrade your world, remerge packages that have a changed USE flag and
> upgrade deep dependencies.
> # emerge --ask --deep --newuse --upgrade world
> 2. rebuild packages that were built against older/removed libaries
> # revdep-rebuild --pretend
>
> If you ever remove a package do it like this:
> 1. remove the package
> # emerge --ask --unmerge package
> 2. remove the dependencies but always check the output. other packages
> might
> use them even though they are not a direct dependency
> # emerge --ask depclean
> 3. rebuild packages that were build against libaries you just removed
> # revdep-rebuild --pretend
>
> This is how I maintain all my systems.
> If anyone has remarks/tips I'd be glad to hear them.
> --
> gentoo-amd64@gentoo.org mailing list
>
>

[-- Attachment #2: Type: text/html, Size: 2567 bytes --]

[gentoo-amd64] Re: Re: Re: libungif and giflib conflict.

[Duncan]

Harm Geerts posted <200511021409.38666.harmgeerts@home.nl>, excerpted
below,  on Wed, 02 Nov 2005 14:09:38 +0100:

> On Wednesday 02 November 2005 05:30, Nick Currier wrote:
>> Looks like that got it guys. Thanks tons for the help.... It seems I broke
>> portage by running only part ~amd64 packages. revdep-rebuild found it but
>> it took twice to fix..... depclean wants to get rid of tons of stuff though
>> so I'm thinking this is a bad idea or I have bigger problems.... Kudos to
>> AMD64 Gentoo for the best support team in open source.
> 
> It's normal for a system that hasn't been maintained the way it should ;)

Seconded.

What depclean does is starting from your world file (and including stuff
in your system profile that's not specifically listed in the world file),
figure out what each package listed there needs to RUN (run-time
dependencies, as opposed to compile-time dependencies), BASED ON CURRENT
USE FLAGS, then unmerge other packages as unnecessary.

This is why it's important to try it with --pretend, first, and check the
list for sanity.  There are a number of reasons something might be listed
for removal that needs to be kept.  

1.  Occasionally, there might be something NOT listed in your world file
(and that isn't a dependency of anything else) that you want.  These are
easy enough to append to your world file, removing them and their
dependencies from the list.

2.  USE flags affect dependencies, in many cases.  If you merged something
with one set of use flags, resulting in it linking against a particular
library, then you changed your USE flags, so it would NOT link against it
now, but you still have the old version, linked against that library,
merged, then depclean will want to remove the library (because the current
USE flags say it isn't needed), but doing so will break the currently
merged package with outdated USE flags linked against it.

This is why it's a good idea to run emerge --newuse (-N) --deep (-D)
--update (-u) first.  Doing so should find those currently merged packages
with outdated USE flags and remerge them with current USE flags, thus NOT
linking against that no longer needed library, allowing it to be unmerged
without killing the stuff that formerly depended on it.

It's also why running revdep-rebuild afterward, not just before, is a good
idea.  Doing so afterward catches anything that slipped thru the cracks
the first time.

3.  Note the emphasized RUNTIME above.  The easiest way to explain this
one is with a real example, taken from my experience.  

Example:  k3b is probably the Linux world's best and most recognized all
around CD/DVD burner, ripper, and media transcoder, all in one.  With
various USE flags set, it'll bring in as dependencies transcode and a
bunch of different media codec libraries, that allow transcode to do its
thing, converting from one media format to another on-the-fly.  k3b of
course then uses transcode as one of its tools, to help it convert between
various formats, as well.

The thing is, as the k3b ebuild is currently setup, transcode and a bunch
of these media codec libraries are configured as MERGE TIME dependencies,
NOT RUNTIME dependencies.  Thus, depclean will want to remove them, which
probably isn't what you want, if you had k3b USE flags setup to pull them
in in the first place.  Appending all the affected packages to the world
file will prevent depclean from removing them as unneeded at runtime.

That's probably one of the more extreme examples of where depclean will be
almost GUARANTEED to do the wrong thing, if you don't check what it's
going to do, and do that append before letting it do its thing.  However,
the same principle likely applies in other cases as well.  Even where
packages may not be actually used except to compile packages you /do/ use,
you may want them in your world file, just to prevent depclean from
unmerging them, and therefore having to remerge them the next time the
package you want, that has them as merge-time only dependencies, gets
upgraded.

ALTERNATIVE/HINT:  This is yet another place where FEATURES=buildpkg comes
in handy.  If you have portage automatically creating binary packages of
everything you merge, you don't have to be quite as careful with depclean.
If it removes something you decide you want, simply remerge the binpkg,
avoiding the hassle of having to recompile the package from scratch.  If
you are NOT running FEATURES=buildpkg, yet you aren't sure if something's
needed or not, try using quickpkg to package up the existing package as
currently deployed on your system, before unmerging it.  As above, if you
find you needed the package after all, simply emerge -k it, and the
binpkg you quickpackaged should be remerged, avoiding that extra recompile
time.

> 1. Look over the list of packages that would be unmerged with:
> # emerge --pretend depclean
> 2. Inject the packages that should not be removed in your world file with:
> # emerge --noreplace <package name>

Hmm...  That --noreplace is a new one on me.  I normally simply

echo <category/pkg> >> /var/lib/portage/world

That appends the echoed cat/package to the end of the named file,
accomplishing what we are after.  The only down side to doing it manually
(using echo) is if you typo.  Still, that's not hard to catch and fix, if
depclean still wants to remove the package you (thought you) just added. 
Newer versions of portage (don't believe it's in stable portage yet) even
have an emaint command that removes the bad lines for you.

> Repeats steps 1 and 2 untill you are satisfied. 

> 3. clean the remaining packages with:
> # emerge --ask depclean

Note that there's nothing magical about the depclean command itself, other
than the fact that it automatically computes the dependencies and finds
what can be unmerged, for you.  Once it comes to the unmerge itself,
that's really all it does.

Consequently, here, I'll usually do an emerge --pretend depclean, then
simply use the list to add packages to the world file or manually emerge
--unmerge them.  I very rarely run emerge depclean without the --pretend;
that is, I don't often let it do the unmerging on its own.  Rather, I use
it to get a list, and do the unmerging directly, myself.  No big deal,
it's just a matter of style, but I feel more in control doing it myself.
=8^)

One thing about doing the unmerges manually, however, is that if the list
is a bit long, one can unmerge stuff as they decide they don't need it, or
add it to the world file as they decide they do, thus dealing with the
list a bit at a time.  Whittling the list down this way, one can
repeatedly run depclean pretend, addressing just a few packages each time,
until the list gets to a rather more manageable size -- something that
might help if depclean hasn't been run in awhile.

> 4. rebuild packages that were built against older/removed libaries:
> # revdep-rebuild --pretend (part of app-portage/gentoolkit)
> 
> In order to keep your system clean in the future upgrade world like
> this: 
> 1. upgrade your world, remerge packages that have a changed USE
> flag and upgrade deep dependencies.
> # emerge --ask --deep --newuse --upgrade world 
> 2. rebuild packages that were built against older/removed libaries 
> # revdep-rebuild --pretend
> 
> If you ever remove a package do it like this:
> 1. remove the package 
> # emerge --ask --unmerge package
> 2. remove the dependencies but always check the output. other packages
> might use them even though they are not a direct dependency
> # emerge --ask depclean
> 3. rebuild packages that were build against libaries you just removed 
> # revdep-rebuild --pretend
> 
> This is how I maintain all my systems. If anyone has remarks/tips I'd be
> glad to hear them.

Very well written!  My tips, mainly the FEATURES=buildpkg or quickpkg
thing, to get binary packages and avoid a possible recompile during a
possible remerge, if you are unsure, and the individual package removal
thing, are above, but they are mainly a matter of personal style.  Your
system hygiene routine is top notch!

Two more things...

1.  I already mentioned one of the new features of the new portage
(2.0.53, now in the rc stage in ~arch), emaint, that helps clean invalid
entries out of the world file.  The new portage has another useful new
tool as well, eclean.  eclean is designed to help manage the accumulated
source tarballs in $DISTDIR, cleaning out the ones that no longer match
anything in portage, by default, or if desired, cleaning out all the
tarballs that don't match packages currently merged (older tarballs
for packages with ebuilds still in portage, mainly).  For those using
FEATURES=buildpkg, eclean can manage the $PACKAGEDIR the same way,
deleting binary packages no longer matching anything in portage by
default, or getting stricter and deleting packages not matching stuff
currently merged, if desired.

eclean started out as one of several tools authored and contributed
by Gentoo users, that did much the same thing.  It was selected for
inclusion in portage because it matched the way portage worked already,
and because it did its job well.  For those still running portage 2.0.52
(stable), eclean is available as a separate package, altho it's not in the
tree.  I believe it can be found in the forums.

2.  All this should reemphasize the role of the world file.  It should
list all your "leaf" packages, for the most part, executables.  It should
NOT list "trunk and branch" packages, dependencies of the leaves, for the 
most part, libraries and the like.

The problem with branch dependencies listed in the world file is that when
the leaf dependencies that use them are no longer needed and are unmerged,
depclean still won't try to remove them, because they are listed in the
world file, even tho they are no longer needed.  OTOH, not listing leaf
dependencies in the world file means depclean will try to remove them,
when they are something you WANT to keep. 

Depclean, therefore, is the only tool around that helps to remove stale
dependencies after the packages using them have been unmerged.  Without
it, the leaf packages may be removed from the world file and unmerged, but
the dependencies they brought in continue to hang around, becoming a
breeding ground for possible bugs and security vulnerabilities, in
addition to the space they take up and the the directories they fill.

HINT:  For this reason, here, I've created a set of aliases I use instead
of calling emerge directly.  By default, now, I call emerge --oneshot,
which will NOT add stuff I emerge to the world file.  That way, I can
emerge dependencies to my heart's content, without worrying about having
them clogging up my world file.  In the event I'm actually emerging a new
"leaf" package that's not in the world file yet, I either don't use those
aliases, so it's added to the world file, or (more likely since it's
habit) use the aliases, but then add them to my world file manually, the
next time I run depclean and find them listed.

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: libungif and giflib conflict.

[Harm Geerts]

On Wednesday 02 November 2005 21:54, Duncan wrote:
> Hmm...  That --noreplace is a new one on me.  I normally simply
>
> echo <category/pkg> >> /var/lib/portage/world
>
> That appends the echoed cat/package to the end of the named file,
> accomplishing what we are after.  The only down side to doing it manually
> (using echo) is if you typo.  Still, that's not hard to catch and fix, if
> depclean still wants to remove the package you (thought you) just added.
> Newer versions of portage (don't believe it's in stable portage yet) even
> have an emaint command that removes the bad lines for you.

So did I, but now the warning `emerge depclean` produces tells me I can use 
this. I find this rather nice as it is a lot safer and keeps the world file 
free from user errors. For example replacing >> with > would be the most 
destructive user error :P
I have portage 2.0.53_rc7 installed and I'm not sure which version introduced 
--noreplace so it might not be available for everyone yet.

> 2.  All this should reemphasize the role of the world file.  It should
> list all your "leaf" packages, for the most part, executables.  It should
> NOT list "trunk and branch" packages, dependencies of the leaves, for the
> most part, libraries and the like.

Ed Catmur has written a script that prunes the world file.
http://home.jesus.ox.ac.uk/~ecatmur/my-bin/dep
This will tune your world to only list leaf packages.
But this may not always be desired, use at your own discretion.

I've got nothing else to add so I guess this concludes the course "Maintaining 
Gentoo in a nutshell" by Duncan and Harm Geerts :)
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: Re: Re: libungif and giflib conflict.

[Duncan]

Harm Geerts posted <200511022259.51970.harmgeerts@home.nl>, excerpted
below,  on Wed, 02 Nov 2005 22:59:51 +0100:

> On Wednesday 02 November 2005 21:54, Duncan wrote:
>> Hmm...  That --noreplace is a new one on me.  I normally simply
>>
>> echo <category/pkg> >> /var/lib/portage/world
>>
>> Newer versions of portage (don't believe it's in stable portage yet) even
>> have an emaint command that removes the bad lines for you.
> 
> So did I, but now the warning `emerge depclean` produces tells me I can use 
> this. I find this rather nice as it is a lot safer and keeps the world file 
> free from user errors. For example replacing >> with > would be the most 
> destructive user error :P
> I have portage 2.0.53_rc7 installed and I'm not sure which version introduced 
> --noreplace so it might not be available for everyone yet.

I'm still on rc6, so I guess I need to sync and emerge -uD world. 
However, it's probably in rc6 too, only I didn't notice it in the warning
(<sheepish> as I don't read it as I know what the warning is about... only
they added something! </sheepish>).

Not here, forgetting the second > in >> wouldn't be destructive!  I think
this hint was featured in GWN a while back (yes, it was, comments are good
things! =8^):

-- snip --

# Based on a tips & tricks GWN feature.
# Makes redirection to an existing file an error.
# Use >> instead of > to append, or >| if overwriting is desired.
set -o noclobber

-- snip --

Put that in your .bashrc or whatever (my /etc/profile and .bashrc and all
that are rather seriously customized, here, it's a file called
noclobber.sh in /etc/profile.d/, but my bashrcs and profiles source
everything in /etc/profile.d/ so it's added to them).

That way, using > to redirect to an existing file produces an error saying
it already exists.  The comment gives the solution, use >> to append, or
use >| to force-overwrite the file.

So... "echo whatever > /var/lib/portage/world" would NOT "be the end of my
world" here!  (double entendre/entente)

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: libungif and giflib conflict.

[Sebastian Redl]

Duncan wrote:

>What depclean does is starting from your world file (and including stuff
>in your system profile that's not specifically listed in the world file),
>figure out what each package listed there needs to RUN (run-time
>dependencies, as opposed to compile-time dependencies), BASED ON CURRENT
>USE FLAGS, then unmerge other packages as unnecessary.
>  
>
Actually, that's not 100% correct. If that was so, depclean would never 
remove system packages.
 But it does. On my setup, which is purely udev, depclean wants to 
remove devfsd. It warns me that it wants to remove the system package, 
but it would do it anyway.

Sebastian Redl
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Re: Re: libungif and giflib conflict.

[Harm Geerts]

On Thursday 03 November 2005 01:52, Sebastian Redl wrote:
> Duncan wrote:
> >What depclean does is starting from your world file (and including stuff
> >in your system profile that's not specifically listed in the world file),
> >figure out what each package listed there needs to RUN (run-time
> >dependencies, as opposed to compile-time dependencies), BASED ON CURRENT
> >USE FLAGS, then unmerge other packages as unnecessary.
>
> Actually, that's not 100% correct. If that was so, depclean would never
> remove system packages.
>  But it does. On my setup, which is purely udev, depclean wants to
> remove devfsd. It warns me that it wants to remove the system package,
> but it would do it anyway.

devfsd and udev are responsible for managing the /dev filesystem so the system 
profile needs a package that fills this requirement.

# grep dev-manager /usr/portage/profiles/base/packages
virtual/dev-manager

The gentoo developers decided to make this system requirement depend on a 
virtual so the profile becomes more flexible.

# grep dev-manager /usr/portage/profiles/base/virtuals
virtual/dev-manager			sys-fs/udev

And there we have it, the Gentoo developers have decided they want udev to be 
responsible for managing the /dev filesystem. So we can conclude:
1. devfsd is obsolete and replaced by udev
2. if udev is installed (which it should) then the system profiles requirement 
for a dev-manager has been filled
3. devfsd is no longer required for the system profile and can be removed

Why do I get the warning about unmerging a system package?
Because devfsd still provides virtual/dev-manager, virtual/dev-manager is 
still part of the system profile. So even though Gentoo favors udev over 
devfsd, devfsd still provides functionality that the system profile requires. 
And that's why you get that message.

Note: You can safely unmerge devfsd as long as you've got RC_DEVICES set to 
"auto" or "udev" in /etc/conf.d/rc
-- 
gentoo-amd64@gentoo.org mailing list