coreutils-6.4 ebuild creates binaries (ls, mv, ...) dependent on libacl/libattr even with the "acl" USE flag disabled. I have never turned on the "acl" USE flag, but I do have the "acl" and "attr" packages installed (probably from stage3 long ago). It appears that the mere presence of these two packages during coreutils-6.4 compilation causes the resultant binaries to be dependent. I tried compiling coreutils-5.94-r1 (the previous unmasked version), and it does not have this problem. I'm now facing a catch-22 situation if I attempt to rid myself of "acl" dependency in a normal fashion: I cannot remove the "acl" or "attr" packages because coreutils binaries depend on them, yet I cannot recompile coreutils without that dependency because those two packages are present. Portage 2.1.1-r1 (default-linux/x86/2006.1/server, gcc-4.1.1, glibc-2.4-r4, 2.6.9-gentoo-r9 i686) ================================================================= System uname: 2.6.9-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.80GHz Gentoo Base System version 1.12.6 Last Sync: Tue, 14 Nov 2006 12:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r4 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.8.1-r1, 2.6.17-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium4 -O3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=pentium4 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apache2 berkdb bitmap-fonts cli cracklib crypt cups dlloader dri elibc_glibc fortran gdbm gpm iconv input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog kernel_linux libg++ linguas_en ncurses nls nptl nptlonly pam pcre perl ppds pppd python readline reflection session snmp spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev video_cards_glint video_cards_i128 video_cards_i740 video_cards_i810 video_cards_imstt video_cards_mga video_cards_neomagic video_cards_nsc video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo xml xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
added fix to cvs and it'll be in 6.6-r1 or 6.7, whichever comes sooner ;)
*** Bug 158064 has been marked as a duplicate of this bug. ***
Reopening until the bug is actually fixed _in the tree_.
if you looked _in the tree_ you'd see that it is fixed
(In reply to comment #4) > if you looked _in the tree_ you'd see that it is fixed I might even notice if you ever used the darned changelog, instead of letting people dig in CVS.
heaven forbid you even read the bugs that you're reopening
It's not fixed in the stable x86 version (which is 6.4) so what's the point of all this? As long as 6.4 is stable it should be fixed in 6.4, or am i wrong?
i'm not backporting anything in coreutils-6.x ... you stabilize a new version instead of wasting time on backporting
Well my idea was to prevent people from running into the same systemcrash as i did. So my point was that it could happen to anyone right now with that ebuild. So what's the problem about fixing it in the stable ebuild?
*** Bug 159036 has been marked as a duplicate of this bug. ***
Given that this completely borks your system unless you can get hold of the necessary binary package (without having to cp or mv it from external storage!), surely at least a warning on the acl package (_Before_ it unmerges) is in order? This is a surefire way to put people off if they can follow the rules and still get a completely broken system.
honestly, that is not coreutils' problem you're talking about a portage issue
*** Bug 160995 has been marked as a duplicate of this bug. ***
