$ unrar unrar: /lib/libc.so.6: version `GLIBC_2.4' not found (required by unrar) The above message is the output from trying to run unrar on a machine with glibc-2.3. The ebuild should be updated to include the dependency on glibc. As it wasn't a build time dependency (because I managed to install it), it is a runtime dependency. It was suggested that I assign this to glibc maintainer. $ emerge --info Portage 2.1.2-r9 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r5, 2.6.18-suspend2-r1 i686) ================================================================= System uname: 2.6.18-suspend2-r1 i686 Pentium III (Coppermine) Gentoo Base System release 1.12.9 Timestamp of tree: Wed, 14 Feb 2007 05:30:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium3 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=pentium3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch 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="X aac acpi alsa bash-completion bitmap-fonts bzip2 cracklib cups divx dlloader dmx dri fbcon fbsplash foomaticdb fortran gpm graphviz gtk gtk2 hddtemp iconv injection ipv6 jpeg madwifi midi mmx ncurses nls nptl nptlonly opengl pam perl png ppds python quicktime readline realmedia spell sse tiff truetype truetype-fonts type1-fonts unicode usb vim-syntax win32codecs wmp x86 xinerama xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="savage vesa" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
No, we are not sticking dependencies on glibc anywhere.
Actually, I just realized this if for rar-3.7.0_beta1 (which already has a glibc depend).
3.7.0 now forces glibc-2.4 or newer
app-arch/rar-3.7.0_beta1: nonsolvable depset(rdepends) keyword(amd64) profile (hardened/amd64): solutions: [ >=sys-libs/glibc-2.4 ] app-arch/rar-3.7.0_beta1: nonsolvable depset(rdepends) keyword(amd64) profile (hardened/amd64/multilib): solutions: [ >=sys-libs/glibc-2.4 ] app-arch/rar-3.7.0_beta1: nonsolvable depset(rdepends) keyword(x86) profile (hardened/x86/2.6): solutions: [ >=sys-libs/glibc-2.4 ]
hardened profiles are managed by hardened team (who would have thought?)
hardened will probably just want to mask the whole package since older versions have security issues
just to summarize: ## glsa-check -p $(glsa-check -t all) This system is affected by the following GLSAs: Checking GLSA 200702-04 The following updates will be performed for this GLSA: app-arch/rar-3.7.0_beta1 (3.5.1) ## emerge -p1v =app-arch/rar-3.7.0_beta1 !!! All ebuilds that could satisfy "=app-arch/rar-3.7.0_beta1" have been masked. !!! One of the following masked packages is required to complete your request: - app-arch/rar-3.7.0_beta1 (masked by: package.mask) # needs >=sys-libs/glibc-2.4 ## # emerge -p1v =sys-libs/glibc-2.4-r4 !!! All ebuilds that could satisfy "=sys-libs/glibc-2.4-r4" have been masked. !!! One of the following masked packages is required to complete your request: - sys-libs/glibc-2.4-r4 (masked by: package.mask) # Mask off glibc-2.4 until the approach for SSP compatibilty is # resolved in a way that doesn't break running systems, and we # have a sensible upgrade path. Advise having a static busybox # around if you try it in a live system. # 2006-03-13 kevquinn
It was masked on the 19th. glibc-2.5 should be entering the tree soon (a week or so, hopefully) at which point it can be unmasked.
We should look at backporting a fix for rar if it's not a binary only pkg.
Source is available here http://www.rarlab.com/rar/unrarsrc-3.7.4.tar.gz compiles fine with make -f makefile.unix unrar linux-gate.so.1 => (0x507d8000) libstdc++.so.6 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libstdc++.so.6 (0x50690000) libm.so.6 => /lib/libm.so.6 (0x5066e000) libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/libgcc_s.so.1 (0x50664000) libc.so.6 => /lib/libc.so.6 (0x5054b000) /lib/ld-linux.so.2 (0x507d9000) I haven't tested further, but assuming this is the correct source would it be an acceptable solution to for the ebuild to compile using the makefile?
comment #10 essentially boils down to using the unrar package for the unrar executable instead of the one from the rar package. This is a job for the maintainer of the rar package - which is currently maintainer-needed. Re-assigning to maintainer-needed for whoever picks it up to consider removing the stuff provided by the unrar package from the rar package install, and having rar DEPEND on unrar. Note; rar is a proprietary binary-only commercial product, so we can't tweak it - unrar has source provided and the license permits us to build it, although it has restrictions incompatible with the GPL. I'm not taking it on, as I have little interest in working on commercial binary-only packages, especially ones with license clauses like that of RAR (which in many ways is much worse than a patent, which would at least require open publication of the algorithm).
(In reply to comment #11) I don't really understand why are you requesting? We have unrar-gpl in the tree, and rar/unrar don't block each other at all, so what exactly do you want to remove from where?
I agree with comment #12 and #11. In fact imho if we have unrar-gpl this ebuild should be removed altogether and unrar-gpl should be renamed to unrar.
I assumed that the 'unrar' reported as not working by the original bug reporter, came from the rar package (and that it's binary nature was the reason it wouldn't load against glibc-2.3). I've never installed rar itself, so I don't know. I'm also asserting that there's no problem with the unrar package (I have it installed in various places without any problems). So what I'm suggesting is that we have one source for unrar in the tree, and get the rar package to install unrar rather than provide its own binary version of unrar since the from-source version is obviously a better option (all it takes is for the rar src_install() to remove the unrar binary provided there). The only reason for not doing that would be if upstream releases updates to rar without corresponding timely updates to unrar, where necessary. In other words, app-arch/rar would DEPEND on app-arch/unrar - or perhaps || (app-arch/unrar app-arch/unrar-gpl - and the app-arch/rar src_install would do: dobin rar || die "dobin rar" instead of dobin rar unrar || die "dobin rar unrar" and drop the 'dosym ../rar/bin/unrar /opt/bin/unrar With regards unrar-gpl (1) the version in the tree is significantly out of date, (2) doesn't have a stable version where unrar does, and (3) unrar-gpl latest version doesn't support RAR3. In addition I'm not convinced about the licensing. I fired a question to upstream about it because it seems to me that if they truly do have the rights to distribute their version of unrar under the GPL, then anyone can base a GPL implementation of the rar archiver from those sources (i.e. without touching or looking at anything except GPL code). I doubt that's what the RAR author intended.
Why are you trying to remove anything here? Fine, it doesn't work on hardened, mask it there. No reason to remove working stuff for the rest of people just because hardened is stuck w/ obsolete glibc.
I'm not trying to remove anything; all I'm doing is making a suggestion for whoever does pick up the binary commercial rar package, to help avoid unnecessary duplication in the tree should they wish to do so. As you know, I masked rar itself on the hardened profile a month ago now, so there's no need to concern yourself with that. For the record, the reason the binary-only package requires glibc-2.4 is that it has been built with the stack-protector enabled. On the licensing of unrar-gpl, I have now confirmed with the author that he does indeed have permission to distribute it under the GPL, despite the fact that it would allow someone to write an archiver by effectively providing GPL documentation on the rar format and decompression algorithm. Previously this could not even be considered, as the license for both rar _and_ unrar prohibit users from authoring a rar archiver. Obviously writing a compression algorithm is non-trivial as it's far from just an inverse of the decompression algorithm - so perhaps the rar author feels that's a good enough barrier for his purposes (my feeling is that it probably is).
>=glibc-2.4 no longer masked on hardened, nothing to do here.
