Gentoo Archives: gentoo-amd64

From: Mansour Al Akeel <mansour.alakeel@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re: failing to emerge update
Date: Wed, 14 Oct 2009 17:37:36
Message-Id: 2a21586d0910141037x26acfd61ge16294c6591cdf2d@mail.gmail.com
In Reply to: [gentoo-amd64] Re: failing to emerge update by Duncan <1i5t5.duncan@cox.net>
1 I did revdep-rebuild and things went fine. When I did --depclean, It
2 removed many necessary packages. And I can not even complete
3 running "emerge system", it fails on one of the packages due to missing alocal !
4
5 I can not even run mutt, as lynx is not there and can not install it as well.
6
7 I run this type of things before going to bed, as it takes time. I
8 should change this habit, and spend time on it when I am not tired. :)
9 I will look into this tonight, or maybe on the weekend. I may have to
10 spend many hours to fix this.
11
12 Normally I run "emerge --update --deep --newuse world" every two
13 weeks, but I haven't done this for more than 2 months. I don't this
14 should be an issue.
15
16
17 On Tue, Oct 13, 2009 at 11:39 AM, Duncan <1i5t5.duncan@×××.net> wrote:
18 > Mansour Al Akeel posted on Tue, 13 Oct 2009 10:25:15 -0300 as excerpted:
19 >
20 >> I lost the output from the previos build, and unable to regenerate the
21 >> issue after fooliwnf libxcb update guilde. But now I am stuck with
22 >> another error, when bulllding gcc.
23 >>
24 >>
25 >> /var/tmp/portage/sys-devel/gcc-4.1.2/
26 >
27 > gcc-4.1.2 ?  gcc 4.1 is a bit outdated.  You /may/ be able to simply
28 > unmerge it.  What versions of gcc do you have installed, anyway?  It's
29 > likely you have a 4.3 version, as gcc-4.3.2-r3 is the latest keyworded
30 > stable for amd64.
31 >
32 > A caution, however.  Until your whole system is rebuilt with the newer
33 > gccs, some C++ packages in particular may still link to the old
34 > versions.  But it should at least be possible to ignore the old gccs for
35 > the moment (emerge --resume --skipfirst if necessary) and build
36 > everything else.  If you're using FEATURES=buildpkg, it's easy enough to
37 > unmerge a package, see if anything breaks (run revdep-rebuild and see if
38 > there's anything that needs rebuilt, and hope it rebuilds fine), and
39 > remerge the binpkg if necessary.  That's what I'd do.
40 >
41 > If you're not running FEATURES=buildpkg, I'd suggest you consider it.
42 > Right before a system-wide rebuild is a great time to turn it on. =:^)
43 > But if you're not, you can use quickpkg to create a binpkg of a
44 > particular package before removing it for testing.  That way you still
45 > get the binpkg, and can remerge it if necessary, if you find you still
46 > need it.
47 >
48 > Anyway... after updating gcc to 4.3.2-r3 if you don't have it, and gcc-
49 > config-ing to it, you could emerge --emptytree @system @world so
50 > everything is built with it, and then unmerge older gcc versions,
51 > including the 4.1.2 that's giving you issues ATM.
52 >
53 > FWIW, on ~amd64, the only gcc I have currently installed is 4.4.1, as I
54 > unmerged earlier versions after I had rebuilt the entire system with it.
55 > I do remember having some issues rebuilding earlier gccs at one point,
56 > but with the entire system (other than those gccs) building with 4.4.1, I
57 > was able to unmerge them instead of rebuild them.
58 >
59 > Of course, I always do --update --deep --newuse, generally a couple times
60 > a week, and revdep-rebuild and --depclean afterward, to make sure the
61 > system stays consistent and keep the cruft to a minimum.  If you've let
62 > it build up by not regularly using --update --deep and not regularly
63 > doing --depcleans and revdep-rebuilds, you are likely to have quite some
64 > problems getting the system back in shape, as there will be quite some
65 > cruft buildup to clean out, and doing it incrementally as the updates
66 > show up is MUCH easier than letting it buildup and trying to do it all at
67 > once.
68 >
69 > --
70 > Duncan - List replies preferred.   No HTML msgs.
71 > "Every nonfree program has a lord, a master --
72 > and if you use the program, he is your master."  Richard Stallman
73 >
74 >
75 >