[gentoo-user] gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[gentoo-user] gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[michael]

I'm upgrading my gcc from 3.x to 4.x. I've done the gcc switching, and now I'm
updating my system.

The recommended steps are:

   # emerge -eav system
   # emerge -eav world

While emerging my system I received a message suggesting I run revdep-rebuild:

   warning - be sure to run revdep-rebuild now

My question is, should I run revdep-rebuild right after emerging the system,
or should I wait until after I emerge world? My concern was that in between,
my system is in an unstable intermediate state, and it might be damaged by a
revdep-rebuild in between.
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Marc Blumentritt]

michael@michaelshiloh.com schrieb:
> I'm upgrading my gcc from 3.x to 4.x. I've done the gcc switching, and
> now I'm
> updating my system.
> 
> The recommended steps are:
> 
>   # emerge -eav system
>   # emerge -eav world
> 
> While emerging my system I received a message suggesting I run
> revdep-rebuild:
> 
>   warning - be sure to run revdep-rebuild now
> 
> My question is, should I run revdep-rebuild right after emerging the
> system,
> or should I wait until after I emerge world? My concern was that in
> between,
> my system is in an unstable intermediate state, and it might be damaged
> by a
> revdep-rebuild in between.

Well, you rebuild world, which includes all packages you would rebuild
with revdep-rebuild. I would run revdep-rebuild after the rebuild of
world, just to be sure. I also recommend to look through the info
outputs of every emerge, if you missed something, e.g. I had messages
like "rebuild against the new library, than it is save to delete the old
one." If you miss this, then you have cruft libs on your system.

Cheers
Marc


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Richard Fish]

On 9/7/06, michael@michaelshiloh.com <michael@michaelshiloh.com> wrote:
> I'm upgrading my gcc from 3.x to 4.x. I've done the gcc switching, and now I'm
> updating my system.
>
> The recommended steps are:
>
>    # emerge -eav system
>    # emerge -eav world
>
> While emerging my system I received a message suggesting I run revdep-rebuild:
>
>    warning - be sure to run revdep-rebuild now

Um, I believe you can ignore this.  The emerge -eav world will rebuild
all packages...there is nothing that revdep-rebuild will catch that
world won't.

Now if you want to keep /using/ the system while it is rebuilding, you could do:

emerge -eav system  # if already complete, don't repeat
revdep-rebuild --library libstdc++.so.6
emerge -eav world

The revdep-rebuild command will recompile all C++ applications, and
will take a damn long time to run.  But less time than rebuilding
world, and once it completes, your C++ apps should at least be sane.
Otherwise you might get ABI conflicts while the world rebuild is going
on.

Of course, those same C++ apps are going to be rebuilt during the
world step...which is kind of lame.  There are some tricks you can use
to avoid rebuilding things twice...search the archives of this list
for ideas.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Alan McKinnon]

On Thursday 07 September 2006 23:34, michael@michaelshiloh.com 
wrote:
> I'm upgrading my gcc from 3.x to 4.x. I've done the gcc
> switching, and now I'm updating my system.
>
> The recommended steps are:
>
>    # emerge -eav system
>    # emerge -eav world
>
> While emerging my system I received a message suggesting I
> run revdep-rebuild:
>
>    warning - be sure to run revdep-rebuild now
>
> My question is, should I run revdep-rebuild right after
> emerging the system, or should I wait until after I emerge
> world? My concern was that in between, my system is in an
> unstable intermediate state, and it might be damaged by a
> revdep-rebuild in between.

There's no need to run revdep-rebuild, whatever you do it will 
be redundant. The notices you are seeing are primarily intended 
for when you explicitly emerge packages that other packages may 
link to. So everything that might be relevant to the notice you 
see is going to be recompiled anyway when you run 'emerge -e 
world'.

As previously noted on this list, the mention of using 
revdep-rebuild as a shortcut when upgrading gcc was intended 
for the move from 3.3 to 3.4 *only*. The specifics of that 
upgrade made this shortcut possible, in all other upgrades you 
definitely don't use it. i.e. the guide is in need of an uodate 
to make this explicitly clear. If you need more info, ask 
Richard for the inside dope - he's the resident gcc expert 
around here :-)

alan
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Richard Fish]

On 9/8/06, Alan McKinnon <alan@linuxholdings.co.za> wrote:
> Richard for the inside dope - he's the resident gcc expert
> around here :-)

:-P

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Marc Blumentritt wrote:
> <snip>
> I would run revdep-rebuild after the rebuild of
> world, just to be sure. 
>   
< snip>
> Cheers
> Marc
>
>
>   

I did that too.  I'm not sure if it is just me or what but every time I
run revdep-rebuild it wants to emerge gcc again.  It did the same thing
before the gcc upgrade.  If you run it, you may want to post to make
sure it is making sense.  After three runs, I said forget it.  It'll
just have to keep.  I read somewhere it was a bug.  I dunno.

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Marc Blumentritt]

Dale schrieb:
> Marc Blumentritt wrote:
> I did that too.  I'm not sure if it is just me or what but every time I
> run revdep-rebuild it wants to emerge gcc again.  It did the same thing
> before the gcc upgrade.  If you run it, you may want to post to make
> sure it is making sense.  After three runs, I said forget it.  It'll
> just have to keep.  I read somewhere it was a bug.  I dunno.

Did you remove the temporary files of revdep-rebuild from /root?

I had no problems with the upgrade and running revdep-rebuild afterward.
In fact, revdep-rebuild showed me no package at all to rebuild, which
was what I expected.

Cheers
Marc

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Bo Ørsted Andresen]

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

On Friday 08 September 2006 15:00, Dale wrote:
> I'm not sure if it is just me or what but every time I
> run revdep-rebuild it wants to emerge gcc again.  It did the same thing
> before the gcc upgrade.

It is bug #125728 [1]? Otherwise if it continues consider posting the output 
of:

# revdep-rebuild -i -- -vp

[1] http://bugs.gentoo.org/show_bug.cgi?id=125728

-- 
Bo Andresen

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

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Marc Blumentritt wrote:
> Dale schrieb:
>   
>> Marc Blumentritt wrote:
>> I did that too.  I'm not sure if it is just me or what but every time I
>> run revdep-rebuild it wants to emerge gcc again.  It did the same thing
>> before the gcc upgrade.  If you run it, you may want to post to make
>> sure it is making sense.  After three runs, I said forget it.  It'll
>> just have to keep.  I read somewhere it was a bug.  I dunno.
>>     
>
> Did you remove the temporary files of revdep-rebuild from /root?
>
> I had no problems with the upgrade and running revdep-rebuild afterward.
> In fact, revdep-rebuild showed me no package at all to rebuild, which
> was what I expected.
>
> Cheers
> Marc
>
>   

I remove those each time.  It is sort of a habit now.  I run it on
occasion especially if I remove something.  Just to make sure.

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Bo Ørsted Andresen wrote:
> On Friday 08 September 2006 15:00, Dale wrote:
>   
>> I'm not sure if it is just me or what but every time I
>> run revdep-rebuild it wants to emerge gcc again.  It did the same thing
>> before the gcc upgrade.
>>     
>
> It is bug #125728 [1]? Otherwise if it continues consider posting the output 
> of:
>
> # revdep-rebuild -i -- -vp
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=125728
>
>   

This is what your command gave me:

> root@smoker / # revdep-rebuild -i -- -vp
> 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/lib/aqbanking/plugins/0/bankinfo/de.la (requires
> /usr/lib/libaqbanking.la)
>   broken /usr/lib/aqbanking/plugins/0/bankinfo/de.la (requires
> /usr/lib/libgwenhywfar.la)
>   broken /usr/lib/aqbanking/plugins/0/imexporters/ofx.la (requires
> /usr/lib/libaqbanking.la)
>   broken /usr/lib/aqbanking/plugins/0/imexporters/ofx.la (requires
> /usr/lib/libgwenhywfar.la)
>   broken /usr/lib/aqbanking/plugins/0/providers/aqofxconnect.la
> (requires /usr/lib/libaqbanking.la)
>   broken /usr/lib/aqbanking/plugins/0/providers/aqofxconnect.la
> (requires /usr/lib/libgwenhywfar.la)
>   broken /usr/lib/avifile-0.7/ac3pass.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/ac3pass.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/audiodec.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/audiodec.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/ffmpeg.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/ffmpeg.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/mad_audiodec.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/mad_audiodec.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/mp3lame_audioenc.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/mp3lame_audioenc.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/mp3lamebin_audioenc.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/mp3lamebin_audioenc.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/mpeg_audiodec.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/mpeg_audiodec.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/osmjpeg.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/osmjpeg.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/vorbis_audio.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/vorbis_audio.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/win32.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/win32.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/avifile-0.7/xvid4.la (requires
> /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/avifile-0.7/xvid4.la (requires
> /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcjawt.la (requires
> /usr/lib/lib-gnu-java-awt-peer-gtk.la)
>   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgij.la (requires
> /usr/lib/libgcj.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libkio.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libkdesu.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libkwalletclient.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libkdeui.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libkdecore.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libDCOP.la)
>   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> /usr/kde/3.4/lib/libkdefx.la)
>   broken /usr/lib/libaqbankingpp.la (requires /usr/lib/libaqbanking.la)
>   broken /usr/lib/libaqbankingpp.la (requires /usr/lib/libgwenhywfar.la)
>   broken /usr/lib/libaqofxconnect.la (requires /usr/lib/libaqbanking.la)
>   broken /usr/lib/libaqofxconnect.la (requires /usr/lib/libgwenhywfar.la)
>   broken /usr/lib/libaviplay.la (requires /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/libaviplay.la (requires /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/libkbanking.la (requires /usr/lib/libaqbanking.la)
>   broken /usr/lib/libkbanking.la (requires /usr/lib/libgwenhywfar.la)
>   broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavformat.la)
>   broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavcodec.la)
>   broken /usr/lib/libqbanking.la (requires /usr/lib/libaqbanking.la)
>   broken /usr/lib/libqbanking.la (requires /usr/lib/libgwenhywfar.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)
>
> All prepared. Starting rebuild...
> emerge --oneshot -vp =sys-devel/gcc-4.1.1
> ..........
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild   R   ] sys-devel/gcc-4.1.1  USE="doc fortran gcj gtk nls
> -bootstrap -build -hardened -ip28 -ip32r10k -mudflap -multislot -nocxx
> -objc -objc++ -objc-gc -test -vanilla" 0 kB
>
> Total size of downloads: 0 kB
> Build finished correctly. Removing temporary files...
> You can re-run revdep-rebuild to verify that all libraries and binaries
> are fixed. If some inconsistency remains, it can be orphaned file, deep
> dependency, binary package or specially evaluated library.
> root@smoker / # 

I unmerged aqbanking.  It wouldn't compile and I was not using it anyway. 

What you think?  Bug or me having a setting wrong??

Dale

;-)  :-)

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Richard Fish]

On 9/8/06, Dale <teendale@vista-express.com> wrote:
> > Checking dynamic linking consistency...
> >   broken /usr/lib/aqbanking/plugins/0/bankinfo/de.la (requires
> > /usr/lib/libaqbanking.la)

Since you don't have aqbanking installed anymore, just delete these
files, and probably the entire /usr/lib/qabanking directory.  Might
want to run an "equery belongs /usr/lib/aqbanking" first just to make
sure nothing claims ownership of those files first...

> >   broken /usr/lib/avifile-0.7/ac3pass.la (requires
> > /usr/lib/libaviplayavformat.la)
> >   broken /usr/lib/avifile-0.7/ac3pass.la (requires
...

I suspect this is the same as aqbanking..no longer installed, so same
solution.  "Equery belongs" to be sure...

> >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgcjawt.la (requires
> > /usr/lib/lib-gnu-java-awt-peer-gtk.la)
> >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/libgij.la (requires
> > /usr/lib/libgcj.la)

Definitely bug #125728.  I believe comment #29 contains the best
workarounds until a fix is actually applied.

> >   broken /usr/lib/kde3/libk3blibsndfiledecoder.la (requires
> > /usr/kde/3.4/lib/libkio.la)
...

Here again, "equery belongs /usr/lib/kde3/libk3blibsndfiledecoder.la".
 If nothing owns it, just remove it.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Neil Bothwick]

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

On Fri, 08 Sep 2006 16:14:53 -0500, Dale wrote:

> >   broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavformat.la)
> >   broken /usr/lib/libqavm.la (requires /usr/lib/libaviplayavcodec.la)
> >   broken /usr/lib/libqbanking.la (requires /usr/lib/libaqbanking.la)
> >   broken /usr/lib/libqbanking.la (requires /usr/lib/libgwenhywfar.la)
[repeated]
> 
> I unmerged aqbanking.  It wouldn't compile and I was not using it
> anyway. 
> 
> What you think?  Bug or me having a setting wrong??

Did you run fix_libtool_files.sh between merging and unmerging aqbanking?
This changes .la files, which means that their checksums no longer match
the installed versions so portage doesn't remove them. Whether this is a
bug in fix_libtool_files.sh or portage is open for discussion.


-- 
Neil Bothwick

When companies ship Styrofoam, what do they pack it in?

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

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Richard Fish]

On 9/8/06, Dale <teendale@vista-express.com> wrote:
> So basically if these files don't belong to anything, I can safely
> delete them?

Yep.

> On the roach report, me sort of chicken to edit those files.  Will it be
> OK to let it stay like this and let the bug get fixed?  It's been doing
> this a while and I don't !see! any problems.

Yes, as long as you don't mind the revdep-rebuild borkage.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Bo Ørsted Andresen wrote:
>> I'm working on the list above.  So far nothing belongs to anything.
>> Maybe I need a depclean on this thing.  It is a 3 year old install if I
>> recall correctly.
>>     
>
> This has nothing to do with depclean. Neils suggesting that the md5sums were 
> altered by fix_libtool_files.sh and hence not removed seems much more likely. 
> Portage doesn't removed files with altered md5sums..
>
>   

What would be a good way of finding files that were not deleted when
something was upgraded/unmerged?  I thought depclean was different from
what I wanted to say but it got the ball rolling.

Last part, zoooooooom, right over my head I think.  Let's see if I get
this right.  emerge put a file in there, something, me maybe, changed
something so it leaves it alone.  That right??

Gosh I wish someone could just pour all the Gentoo stuff in my head.

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Bo Ørsted Andresen]

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

On Saturday 09 September 2006 05:33, Dale wrote:
> What would be a good way of finding files that were not deleted when
> something was upgraded/unmerged?  I thought depclean was different from
> what I wanted to say but it got the ball rolling.

Depclean is to remove packages that are no longer in or a dependency of 
something in your world file.

> Last part, zoooooooom, right over my head I think.  Let's see if I get
> this right.  emerge put a file in there, something, me maybe, changed
> something so it leaves it alone.  That right??

Yep. 

So just to illustrate:

# touch  /usr/share/vim/vimfiles/plugin/bugsummary.vim

# emerge --unmerge -va gentoo-syntax
>>> These are the packages that would be unmerged:
[SNIP]
>>> Unmerging app-vim/gentoo-syntax-20051221-r1...
No package files given... Grabbing a set.
[SNIP]
<<<        obj /usr/share/vim/vimfiles/plugin/newinitd.vim
<<<        obj /usr/share/vim/vimfiles/plugin/neweselect.vim
<<<        obj /usr/share/vim/vimfiles/plugin/newebuild.vim
<<<        obj /usr/share/vim/vimfiles/plugin/gentoo-common.vim
--- !mtime obj /usr/share/vim/vimfiles/plugin/bugsummary.vim
[SNIP]
--- !empty dir /usr/share/vim
<<<        dir /usr/share/doc/gentoo-syntax-20051221-r1

All the things that has a "<<<" are actually removed. The things with "---" 
are not removed for the reason given in the following column. Since I 
touch'ed  /usr/share/vim/vimfiles/plugin/bugsummary.vim it wasn't removed 
with the reason: "!mtime" which means the last modified time has been altered 
after it was installed. The reason "!empty" is the reason for dirs which 
aren't empty (others packages have installed files in the same dirs...).

After the unmerge is complete the only way to know is that the files no longer 
belong to any package. Of course when I remerge this package in a few minutes 
the files will be overwritten and the mtime will be correct again...

Hope that makes it clear.

-- 
Bo Andresen

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

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Bo Ørsted Andresen wrote:
> On Saturday 09 September 2006 05:33, Dale wrote:
>   
>> What would be a good way of finding files that were not deleted when
>> something was upgraded/unmerged?  I thought depclean was different from
>> what I wanted to say but it got the ball rolling.
>>     
>
> Depclean is to remove packages that are no longer in or a dependency of 
> something in your world file.
>
>   
>> Last part, zoooooooom, right over my head I think.  Let's see if I get
>> this right.  emerge put a file in there, something, me maybe, changed
>> something so it leaves it alone.  That right??
>>     
>
> Yep. 
>
> So just to illustrate:
>
> # touch  /usr/share/vim/vimfiles/plugin/bugsummary.vim
>
> # emerge --unmerge -va gentoo-syntax
>   
>>>> These are the packages that would be unmerged:
>>>>         
> [SNIP]
>   
>>>> Unmerging app-vim/gentoo-syntax-20051221-r1...
>>>>         
> No package files given... Grabbing a set.
> [SNIP]
> <<<        obj /usr/share/vim/vimfiles/plugin/newinitd.vim
> <<<        obj /usr/share/vim/vimfiles/plugin/neweselect.vim
> <<<        obj /usr/share/vim/vimfiles/plugin/newebuild.vim
> <<<        obj /usr/share/vim/vimfiles/plugin/gentoo-common.vim
> --- !mtime obj /usr/share/vim/vimfiles/plugin/bugsummary.vim
> [SNIP]
> --- !empty dir /usr/share/vim
> <<<        dir /usr/share/doc/gentoo-syntax-20051221-r1
>
> All the things that has a "<<<" are actually removed. The things with "---" 
> are not removed for the reason given in the following column. Since I 
> touch'ed  /usr/share/vim/vimfiles/plugin/bugsummary.vim it wasn't removed 
> with the reason: "!mtime" which means the last modified time has been altered 
> after it was installed. The reason "!empty" is the reason for dirs which 
> aren't empty (others packages have installed files in the same dirs...).
>
> After the unmerge is complete the only way to know is that the files no longer 
> belong to any package. Of course when I remerge this package in a few minutes 
> the files will be overwritten and the mtime will be correct again...
>
> Hope that makes it clear.
>
>   
So basically if I mess with a file and then unmerge the program it
belongs to, I have to remember which ones I messed with and delete them
myself?  If I unmerge this in a console and can't read all the "--
!mtime" as they roll by, I'm stuck with orphan files on my rig?  This
needs a fix but I wouldn't want to be the dev to figure this one out.  ;-)

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Neil Bothwick]

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

On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote:

> So basically if I mess with a file and then unmerge the program it
> belongs to, I have to remember which ones I messed with and delete them
> myself?

Yes, because the file is no longer the file portage installed, so it has
no right to remove it.

> If I unmerge this in a console and can't read all the "--
> !mtime" as they roll by, I'm stuck with orphan files on my rig?  This
> needs a fix but I wouldn't want to be the dev to figure this one
> out.  ;-)

This generally isn't a problem, because you normally only edit files
in /etc, which are config protected anyway. It arises here because
fix_libtool_files.sh modifies the .la files. One could argue that it is
the responsibility of that script to check the md5/mtime information and
update it.


-- 
Neil Bothwick

A computer scientist is someone who, when told to "Go to Hell,"
sees the "go to," rather than the destination, as harmful.

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

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Neil Bothwick wrote:
> On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote:
>
>   
>> So basically if I mess with a file and then unmerge the program it
>> belongs to, I have to remember which ones I messed with and delete them
>> myself?
>>     
>
> Yes, because the file is no longer the file portage installed, so it has
> no right to remove it.
>
>   
>> If I unmerge this in a console and can't read all the "--
>> !mtime" as they roll by, I'm stuck with orphan files on my rig?  This
>> needs a fix but I wouldn't want to be the dev to figure this one
>> out.  ;-)
>>     
>
> This generally isn't a problem, because you normally only edit files
> in /etc, which are config protected anyway. It arises here because
> fix_libtool_files.sh modifies the .la files. One could argue that it is
> the responsibility of that script to check the md5/mtime information and
> update it.
>
>
>   

Cheese, I'm learning something.  I already knew that it would not delete
files in /etc/ and now I know why.  LOL  I never put the two together
before you said that.  Who knows, maybe in 20 years I'll be a dev.  O_O 
I'll be too old then though.

I'm working on a fresh install on another hard drive now.  That will
clear out some cruft.  I copied my make.conf file and one other config
file and that is it.  Oh, the kernel's .config.  I knew it was something
outside of /etc. 

Thanks for clearing up my muddy water.  Care to help with the rest now?  LOL

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Bo Ørsted Andresen]

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

On Monday 11 September 2006 23:32, Neil Bothwick wrote:
> On Fri, 08 Sep 2006 23:15:09 -0500, Dale wrote:
> > So basically if I mess with a file and then unmerge the program it
> > belongs to, I have to remember which ones I messed with and delete them
> > myself?
>
> Yes, because the file is no longer the file portage installed, so it has
> no right to remove it.
[SNIP]
> This generally isn't a problem, because you normally only edit files
> in /etc, which are config protected anyway. It arises here because
> fix_libtool_files.sh modifies the .la files. 

I still would prefer if it was stored in a log file somewhere so that if I 
ever stumple upon it I can see where it came from... Haven't gotten around to 
filing any bug about that though.

> One could argue that it is 
> the responsibility of that script to check the md5/mtime information and
> update it.

http://bugs.gentoo.org/show_bug.cgi?id=71265

-- 
Bo Andresen

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

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Ryan Tandy]

Dale wrote:
> Cheese, I'm learning something.  I already knew that it would not delete
> files in /etc/ and now I know why.  LOL  I never put the two together
> before you said that.

Well, the /etc thing is generally more due to CONFIG_PROTECT - it won't 
delete files from /etc regardless of whether or not you've modified 
them, because they're under CONFIG_PROTECTion.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: gcc upgrade from 3.x to 4.x, when should I run revdep-rebuild?

[Dale]

Ryan Tandy wrote:
> Dale wrote:
>> Cheese, I'm learning something.  I already knew that it would not delete
>> files in /etc/ and now I know why.  LOL  I never put the two together
>> before you said that.
>
> Well, the /etc thing is generally more due to CONFIG_PROTECT - it
> won't delete files from /etc regardless of whether or not you've
> modified them, because they're under CONFIG_PROTECTion.

Yea, but now I know that.  Sometimes it takes my light bulb a while to
get brightened up good.  :-(

LOL

Dale

:-)  :-)
-- 
gentoo-user@gentoo.org mailing list