[gentoo-user] revdep-rebuild question

[gentoo-user] revdep-rebuild question

[Mark Knecht]

Hi,
   I'm not clear why revdep-rebuild is showing lots of broken linkages
but then telling me everything is in order and there is no work to do
to clean up the system.

   I haven't seen this before. What's causing it?

   What's the process to get this cleaned up and down to no messages
about broken things?

Thanks,
Mark


gandalf ~ # revdep-rebuild -p
Configuring search environment for revdep-rebuild

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update
will be emerged.

Collecting system binaries and libraries... done.
  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.
  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...
  broken /usr/bin/avibench (requires  libaviplay-0.7.so.0)
  broken /usr/bin/avicap (requires  libaviplay-0.7.so.0 libqavm-0.7.so.0)
  broken /usr/bin/avicat (requires  libaviplay-0.7.so.0)
<SNIP>
  broken /usr/lib/transcode/filter_preview.la (requires /usr/lib/libdv.la)
  broken /usr/lib/transcode/filter_preview.la (requires
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.la)
 done.
  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.
  (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order... done.
  (/root/.revdep-rebuild.5_order)

Dynamic linking on your system is consistent... All done.
gandalf ~ #
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Alan McKinnon]

On Monday 19 February 2007, Mark Knecht wrote:
> Hi,
>    I'm not clear why revdep-rebuild is showing lots of broken
> linkages but then telling me everything is in order and there is no
> work to do to clean up the system.
>
>    I haven't seen this before. What's causing it?
>
>    What's the process to get this cleaned up and down to no messages
> about broken things?
>
> Thanks,
> Mark

My guess would be that portage cannot assign the broken binaries 
(/usr/bin/avibench etc) to an ebuild, and therefore there cannot be 
anything to emerge.

They might be orphan binaries from a previous incomplete unmerge, or 
something locally compiled, or even files installed from a foreign 
package system (.tgz or .rpm perhaps?)

alan


>
>
> gandalf ~ # revdep-rebuild -p
> Configuring search environment for revdep-rebuild
>
> Checking reverse dependencies...
>
> Packages containing binaries and libraries broken by a package update
> will be emerged.
>
> Collecting system binaries and libraries... done.
>   (/root/.revdep-rebuild.1_files)
>
> Collecting complete LD_LIBRARY_PATH... done.
>   (/root/.revdep-rebuild.2_ldpath)
>
> Checking dynamic linking consistency...
>   broken /usr/bin/avibench (requires  libaviplay-0.7.so.0)
>   broken /usr/bin/avicap (requires  libaviplay-0.7.so.0
> libqavm-0.7.so.0) broken /usr/bin/avicat (requires 
> libaviplay-0.7.so.0)
> <SNIP>
>   broken /usr/lib/transcode/filter_preview.la (requires
> /usr/lib/libdv.la) broken /usr/lib/transcode/filter_preview.la
> (requires
> /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.la)
>  done.
>   (/root/.revdep-rebuild.3_rebuild)
>
> Assigning files to ebuilds... done.
>   (/root/.revdep-rebuild.4_ebuilds)
>
> Evaluating package order... done.
>   (/root/.revdep-rebuild.5_order)
>
> Dynamic linking on your system is consistent... All done.
> gandalf ~ #



-- 
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?

Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Mark Knecht]

On 2/19/07, Alan McKinnon <alan@linuxholdings.co.za> wrote:
> On Monday 19 February 2007, Mark Knecht wrote:
> > Hi,
> >    I'm not clear why revdep-rebuild is showing lots of broken
> > linkages but then telling me everything is in order and there is no
> > work to do to clean up the system.
> >
> >    I haven't seen this before. What's causing it?
> >
> >    What's the process to get this cleaned up and down to no messages
> > about broken things?
> >
> > Thanks,
> > Mark
>
> My guess would be that portage cannot assign the broken binaries
> (/usr/bin/avibench etc) to an ebuild, and therefore there cannot be
> anything to emerge.
>
> They might be orphan binaries from a previous incomplete unmerge, or
> something locally compiled, or even files installed from a foreign
> package system (.tgz or .rpm perhaps?)
>
> alan
>
>

Alan,
   Seems reasonable. Would I (Could I?) then do an equery depends on
each binary and assuming nothing depends on it remove them by hand
without causing damage?

   I'd want to do another revdep-rebuild every so often to ensure that
things remained consistent.

Thanks,
Mark
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Jakob Buchgraber]

Mark Knecht wrote:
> Hi,
>   I'm not clear why revdep-rebuild is showing lots of broken linkages
> but then telling me everything is in order and there is no work to do
> to clean up the system.
>
>   I haven't seen this before. What's causing it?
>
>   What's the process to get this cleaned up and down to no messages
> about broken things?
>
> Thanks,
> Mark
>
>
> gandalf ~ # revdep-rebuild -p
> Configuring search environment for revdep-rebuild
>
> Checking reverse dependencies...
>
> Packages containing binaries and libraries broken by a package update
> will be emerged.
>
> Collecting system binaries and libraries... done.
>  (/root/.revdep-rebuild.1_files)
>
> Collecting complete LD_LIBRARY_PATH... done.
>  (/root/.revdep-rebuild.2_ldpath)
>
> Checking dynamic linking consistency...
>  broken /usr/bin/avibench (requires  libaviplay-0.7.so.0)
>  broken /usr/bin/avicap (requires  libaviplay-0.7.so.0 libqavm-0.7.so.0)
>  broken /usr/bin/avicat (requires  libaviplay-0.7.so.0)
> <SNIP>
>  broken /usr/lib/transcode/filter_preview.la (requires /usr/lib/libdv.la)
>  broken /usr/lib/transcode/filter_preview.la (requires
> /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libstdc++.la)
> done.
>  (/root/.revdep-rebuild.3_rebuild)
>
> Assigning files to ebuilds... done.
>  (/root/.revdep-rebuild.4_ebuilds)
>
> Evaluating package order... done.
>  (/root/.revdep-rebuild.5_order)
>
> Dynamic linking on your system is consistent... All done.
> gandalf ~ #
All options being passed to revdep-rebuild are also passed to emerge. So 
write only
revdep-rebuild instead of revdep-rebuild -p (pretend)

Cheers,
jay

-- 
My system configuration (Gentoo Linux): http://www.linux-stats.org/index.php?c=userpage&sys=810
Registered Linux User #373457

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: revdep-rebuild question

[dnlt0hn5ntzhbqkv51]

> Alan,
>    Seems reasonable. Would I (Could I?) then do an equery depends on
> each binary and assuming nothing depends on it remove them by hand
> without causing damage?
>
>    I'd want to do another revdep-rebuild every so often to ensure that
> things remained consistent.

Makes sense to me - doing the equery on the package that installed the  
binary (which may have a name unrelated).

IIUC, there are two tools useful for second/third opinions for this task;  
dep and pquery. Here's an example of their use on fftw:

dep -L fftw

pquery --vdb --revdep sci-libs/fftw

And as you idicated, do a revdep-rebuild after the manual deletion.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Boyd Stephen Smith Jr.]

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

On Monday 19 February 2007, "Mark Knecht" <markknecht@gmail.com> wrote 
about 'Re: [gentoo-user] revdep-rebuild question':
> On 2/19/07, Alan McKinnon <alan@linuxholdings.co.za> wrote:
> > On Monday 19 February 2007, Mark Knecht wrote:
> > >    I'm not clear why revdep-rebuild is showing lots of broken
> > > linkages but then telling me everything is in order and there is no
> > > work to do to clean up the system.
> > >
> > >    I haven't seen this before. What's causing it?
> >
> > They might be orphan binaries from a previous incomplete unmerge, or
> > something locally compiled, or even files installed from a foreign
> > package system (.tgz or .rpm perhaps?)
>
>    Seems reasonable. Would I (Could I?) then do an equery depends on
> each binary and assuming nothing depends on it remove them by hand
> without causing damage?

Probably want to do a (b)elongs instead of a (d)epends, but yes, assuming 
you aren't maintaining those binaries outside of portage's control.  (E.g. 
locally compiled or from a foreign package system.)

>    I'd want to do another revdep-rebuild every so often to ensure that
> things remained consistent.

Yep.  revdep-rebuild used to be part of my daily system maintenance script 
(and will be put back once I figure out a good way to use paludis instead 
of emerge for the remerge part).

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     
New GPG Key!  Old key expires 2007-03-25.  Upgrade NOW!

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

[gentoo-user] Re: revdep-rebuild question

[7v5w7go9ub0o]

> Alan,
>    Seems reasonable. Would I (Could I?) then do an equery depends on
> each binary and assuming nothing depends on it remove them by hand
> without causing damage?
>
>    I'd want to do another revdep-rebuild every so often to ensure that
> things remained consistent.
>


Makes sense to me - doing the equery on the package that installed the
binary (which may have a name unrelated).

IIUC, there are two tools useful for second/third opinions for this task;
dep and pquery. Here's an example of their use on fftw:

dep -L fftw

pquery --vdb --revdep sci-libs/fftw

And as you idicated, do a revdep-rebuild after the manual deletion.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Neil Walker]

Jakob Buchgraber wrote:
> All options being passed to revdep-rebuild are also passed to emerge. 
> So write only
> revdep-rebuild instead of revdep-rebuild -p (pretend)

How would that help the OP? If it finds nothing to emerge with the -p 
option, removing it will do nothing - other than waste some time.



Be lucky,

Neil

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Alan McKinnon]

On Monday 19 February 2007, Mark Knecht wrote:
> On 2/19/07, Alan McKinnon <alan@linuxholdings.co.za> wrote:
> > On Monday 19 February 2007, Mark Knecht wrote:
> > > Hi,
> > >    I'm not clear why revdep-rebuild is showing lots of broken
> > > linkages but then telling me everything is in order and there is
> > > no work to do to clean up the system.
> > >
> > >    I haven't seen this before. What's causing it?
> > >
> > >    What's the process to get this cleaned up and down to no
> > > messages about broken things?
> > >
> > > Thanks,
> > > Mark
> >
> > My guess would be that portage cannot assign the broken binaries
> > (/usr/bin/avibench etc) to an ebuild, and therefore there cannot be
> > anything to emerge.
> >
> > They might be orphan binaries from a previous incomplete unmerge,
> > or something locally compiled, or even files installed from a
> > foreign package system (.tgz or .rpm perhaps?)
> >
> > alan
>
> Alan,
>    Seems reasonable. Would I (Could I?) then do an equery depends on
> each binary and assuming nothing depends on it remove them by hand
> without causing damage?

You're on the right track with the wrong command. 'equery depends 
<package> tells you what packages depend on the given package. You 
want 'equery belongs <binary>' which will tell you what ebuild put the 
file there. You get three cases:

1. It's an orphan, left over from an unmerge that wasn't fully 
successful. if you don't need them, delete them.
2. A package was installed, and it created it's own binaries for it's 
own use. Portage didn't put them there so doesn't know about them. This 
is rare and usually applies to config and other data files. In this 
case it's up to you to figure out what the file is as portage can't 
help.
3. You compiled something long ago by hand and didn't put it 
in /usr/local/ like you were supposed to, and used /usr/ instead. In 
this case you get to remember what you did by yourself :-)

>    I'd want to do another revdep-rebuild every so often to ensure
> that things remained consistent.

revdep-rebuild after every 'emerge -uND world' is highly recommended

alan



-- 
Optimists say the glass is half full,
Pessimists say the glass is half empty,
Developers say wtf is the glass twice as big as it needs to be?

Alan McKinnon
alan at linuxholdings dot co dot za
+27 82, double three seven, one nine three five
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] revdep-rebuild question

[Neil Bothwick]

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

On Tue, 20 Feb 2007 09:42:13 +0200, Alan McKinnon wrote:

> 1. It's an orphan, left over from an unmerge that wasn't fully 
> successful. if you don't need them, delete them.
> 2. A package was installed, and it created it's own binaries for it's 
> own use. Portage didn't put them there so doesn't know about them. This 
> is rare and usually applies to config and other data files. In this 
> case it's up to you to figure out what the file is as portage can't 
> help.
> 3. You compiled something long ago by hand and didn't put it 
> in /usr/local/ like you were supposed to, and used /usr/ instead. In 
> this case you get to remember what you did by yourself :-)

4. The file was installed by portage and subsequently modified. When
you uninstalled the package, portage didn't remove this file because the
mtime differed from what it had installed.

This typically occurs with .la files (Mark's revdep-rebuild output showed
some of these) after fix_libtool_files.sh has changed them.


-- 
Neil Bothwick

Top Oxymorons Number 11: Terribly pleased

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

[gentoo-user] revdep-rebuild question

[Hartmut Figge]

Greetings,

after the emerge -uDN world of today i proceeded with revdep-rebuild
which found nothing to to. But i noticed, that the emerge recommended to
execute revdep-rebuild --library='libosp.so.*'. Doing this two packages
were found and emerged.

Now, shouldn't these have been found already by the previous revdep-rebuild?

Hartmut
-- 
Usenet-ABC-Wiki http://www.usenet-abc.de/wiki/
Von Usern fuer User  :-)

Re: [gentoo-user] revdep-rebuild question

[Paul Hartman]

On Mon, Jul 25, 2011 at 5:20 PM, Hartmut Figge <h.figge@gmx.de> wrote:
> Greetings,
>
> after the emerge -uDN world of today i proceeded with revdep-rebuild
> which found nothing to to. But i noticed, that the emerge recommended to
> execute revdep-rebuild --library='libosp.so.*'. Doing this two packages
> were found and emerged.
>
> Now, shouldn't these have been found already by the previous revdep-rebuild?

I believe --library rebuilds everything that uses that library, not
broken packages.

Re: [gentoo-user] revdep-rebuild question

[Paul Hartman]

On Mon, Jul 25, 2011 at 5:30 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 5:20 PM, Hartmut Figge <h.figge@gmx.de> wrote:
>> Greetings,
>>
>> after the emerge -uDN world of today i proceeded with revdep-rebuild
>> which found nothing to to. But i noticed, that the emerge recommended to
>> execute revdep-rebuild --library='libosp.so.*'. Doing this two packages
>> were found and emerged.
>>
>> Now, shouldn't these have been found already by the previous revdep-rebuild?
>
> I believe --library rebuilds everything that uses that library, not
> broken packages.

To test my theory you can run the command again and see if it finds
the same 2 packages again. :)

Re: [gentoo-user] revdep-rebuild question

[Bill Kenworthy]

On Mon, 2011-07-25 at 17:30 -0500, Paul Hartman wrote:
> On Mon, Jul 25, 2011 at 5:30 PM, Paul Hartman
> <paul.hartman+gentoo@gmail.com> wrote:
> > On Mon, Jul 25, 2011 at 5:20 PM, Hartmut Figge <h.figge@gmx.de> wrote:
> >> Greetings,
> >>
> >> after the emerge -uDN world of today i proceeded with revdep-rebuild
> >> which found nothing to to. But i noticed, that the emerge recommended to
> >> execute revdep-rebuild --library='libosp.so.*'. Doing this two packages
> >> were found and emerged.
> >>
> >> Now, shouldn't these have been found already by the previous revdep-rebuild?
> >
> > I believe --library rebuilds everything that uses that library, not
> > broken packages.
> 
> To test my theory you can run the command again and see if it finds
> the same 2 packages again. :)
> 

A quick look at the ebuild for opensp shows that it will always print
that message - doesnt test if its really needed, and the revdep-rebuild
reccomendation will always rebuild "all" matching libs it finds - not
just ones that really need building.

BillK