Hey, you removed coreutils. I did this once: go to http://dev.gentoo.org/~avenj/bins/ get the corutil package, and untar it in / (you should still have tar and wget ...)
By the way this coreutils is for i686 if you have an older system, CFLAGS="what you want ..." emerge -b coreutils on an other gentoo distro you have and then copy the corutils.tar.gz that is in /usr/portage/packages on this computer, and do the same thing: unter in /

Then your emerge should work again and just emerge corutils to ensure everything is in order

I did the same thing 6 months ago: coreutils is just crucial, but I didn't know what it was. emerge depclean is REALLY dangerous. If you need some other package and don't have an other gentoo system to rescue yours, I may compile you a few tarballs if you want._________________http://petition.eurolinux.org/ - Petition against ePatents
L'essence de la finesse

Actually, coreutils wasn't unmerged. There are two files that went walkabout: libattr.so and libacl.so. The coreutils package in the stage3 tarball is compiled with USE="acl". This, I think, is a little silly. So instead of downloading the coreutils binary package, you just need to type:

Code:

ls

This will bomb out with an error message about a missing library. BUT: it's on the LiveCD! So boot up using the LiveCD and copy that file to where it's supposed to be (after mounting your partitions of course). Then go back into your system and you'll find that doing "ls" will complain about another file - copy that one across to where it should be too.

Then you'll have a working set of coreutils. So all you need to do now is:

Code:

emerge --oneshot coreutils

--oneshot is used so that coreutils doesn't get recorded in your world file - it doesn't belong there, it lives in the system profile - and then you can remove those two files you copied across again. NB: It's actually recommended to get rid of them once you've done this - DON'T just leave them there.

"emerge depclean" isn't dangerous except for when you've changed the USE flags of something critical. Such as, for example, coreutils! So I would suggest that making binary packages of everything is probably a good idea if you've used a stage3 tarball when installing Gentoo._________________Reality is for those who can't face Science Fiction.

Well, emerge depclean wants to remove modutils, attr and acl,
and I guess that they are important packages for the system to work fine. However I didn't touch the USE flags. Just submitted a bug report.

No no, no bug. However, I think emerge depclean should be patched to check using ldd that coreutils isn't linking against attr and/or acl?

If you want to check whether or not it's safe to unmerge attr and acl, I have a script you can use that will work it out for you. The link is below. Modutils is deprecated in favour of module-init-tools, so that can go.

On my system, this comes up with two packages as runtime-dependencies (i.e., their binaries will break if depclean unmerges them) - glibc and ncurses. If you get acl or attr as well, you should re-emerge coreutils before you allow depclean to get rid of acl and/or attr._________________Reality is for those who can't face Science Fiction.

Yes. Modutils is for 2.4 kernels and early 2.5 kernels; later 2.5 kernels and all 2.6 kernels (obviously 2.6.5 included) use module-init-tools instead. So it's safe to get rid of it._________________Reality is for those who can't face Science Fiction.

O.K. !!
I followed your advices in another post and recompiled coreutils like this:

USE="-acl" emerge coreutils
revdep-rebuild

and safely removed attr acl and modutils. Thanks!

Just clarify me one more thing:
as one can see in /etc/make.profile/make.defaults stage 2 and 3 of the 2004.1 release were compiled with USE="acl":
GRP_STAGE23_USE="ipv6 pam tcpd readline nls ssl gpm perl python berkdb acl ncurses"

but then acl is missing from the default USE flags, just 4 lines below:

Well, it depends whether or not you want to use POSIX Access Control Lists or not. Personally I don't, and haven't found a use for them yet. So I have USE="-acl" in make.conf. But there definitely shouldn't be a discrepancy - thanks for bringing that to my attention, I'll have a look for a bug to file..._________________Reality is for those who can't face Science Fiction.

Well, guess that only the developers have the "right" answer.
I wanna thank you for your posts, I've found a lot searching through these forums, you're really helpful and I promise not to emerge -UD world!

Then, as the juri points out, the USE variable for the system changes in
such a way to omit "acl". I see this as a HIDDEN CHANGE on the part of
the USE variable when it goes from a setting like that of GRP_STAGE23_USE
to the normal one, below it, except for a single use flag that affects
coreutils! Note that 11 of 12 use flags are dutifully copied to the USE
variable for the system at normal runtime. Why not copy all of them?
What problems would that cause? It appears to me it would actually
reduce the number of problems that users may encounter.

This could definitely be categorized as a bug if such an opportunity for
failure traps so many users. I did not expect a freshly built system would
fail an "emerge depclean".

The bottom line is that a completed stage3 build, post an 'emerge sync'
and 'emerge world' does not pass a simple test of an emerge depclean.
Would this be an accurate characterization? Would that not be considered
broken?

I think it is a bug becasue a user should be penalized for NOT KNOWING
about the super-secret tweak that needs to be performed after booting
from your own kernel on your root partition (instead of the livecd). What
kind of breakage would we get if 6 or 8 of the USE flags in the
GRP_STAGE23_USE variable suddenly disappeared once you started
booting from your own kernel and root partition? That appears to be
what is happening here.

If 'acl' were replicated in the USE variable on line 21 in
/etc/make.profile/make.defaults,
then, an experienced user can disable it in their local
/etc/make.conf file's USE variable. That would be in the spirit of
"those that know" can disable it. But those that are unaware should
not be fubar'd by it.

Is the act of allowing an avoidable and fatal gotcha, genuinely in the
spirit of The Gentoo Way? I think not.

I am a relative newbie so would like some guidance on my next steps.
Add -acl to USE flags?
emerge --oneshot coreutils (because I did not use --oneshot before) ?
rm libattr.so.1.1.0 ?
rm libacl.so.1.1.0 ?
rm libattr.so ?
rm libacl.so ?_________________RobFish

After copying all of the acl and attr libraries from the livecd, everything works fine now. Except when I run ldconfig, the output informs me that it expects libacl.so.1 and libattr.so.1 to be symbolic links. Since everything works now, I'd be happy to leave it as-is or to make those files symbolic links to make ldconfig act like my computer isn't really duct-taped together with the live-cd's libraries; however, I'd prefer to know why these files must be symbolic links (libacl.so.what?), since this recent foray into the Mysterious World of /Lib illustrates a serious gap in my knowledge of how Linux actually works.