Both sys-libs/lwp-2.2 and net-fs/openafs-1.4.5 (and openafs-1.4.4, too I think) try to install: /usr/lib64/liblwp.a Reproducible: Always Steps to Reproduce: 1. Turn on collision protection. 2. Emerge lwp-2.2. 3. Emerge openafs-1.4.5 Actual Results: File collision protection stopped openafs from installing. Expected Results: openafs and lwp should not conflict.
To be expected when you have two forks of the same codebase, I guess... Suggestions on how this should be fixed are welcome :)
Sorry, my mouse aim isn't what it used to be...
I have a similar problem on x86 with sys-libs/lwp-2.2 & net-fs/openafs-1.4.6 installing: /usr/lib/liblwp.a Reproducible: Always Is there a fix yet? Does the conflict break either package?
Sorry it took so long to get around to this, but I think that I found the problem. The AFS support for gdm-2.20.* pulls in both lwp and openafs, which seems wrong because lwp and openafs have a file collision. grep -n openafs gdm-*.ebuild gdm-2.20.0.ebuild:44: afs? ( net-fs/openafs sys-libs/lwp ) gdm-2.20.1.ebuild:44: afs? ( net-fs/openafs sys-libs/lwp ) gdm-2.20.2.ebuild:43: afs? ( net-fs/openafs sys-libs/lwp ) gdm-2.20.3.ebuild:43: afs? ( net-fs/openafs sys-libs/lwp ) I don't know if gdm is the only offender in this category, but it should probably be checked out.
Openafs only seems to install liblwp.a. Where's the rest? (*.so and stuff) Just curious, because maybe openafs isn't really supposed to install any version of liblwp.
On my system, openafs also installs /usr/include/lwp.h. (Both for openafs-1.4.5-r2 and openafs-1.4.6). An so-file is not mandatory if a static library is given.
> On my system, openafs also installs /usr/include/lwp.h. (Both for > openafs-1.4.5-r2 and openafs-1.4.6). An so-file is not mandatory if a static > library is given. right, and while the one lwp.h is in /usr/include, the other is in /usr/include/lwp. Hmm. Would it be a sollution to have openafs not installing any lwp components? Or what kind of hell would we head to, if we don't install openafs's lwp stuff? (lwp seems to be linked statically into all openafs components already)
This behavior still exists in gnome-base/gdm-2.20.7 - any work towards a solution? I found a tentative workaround by emerging lwp, then removing the lwp-installed liblwp.a and emerging openafs. Nothing seems to break too terribly. # emerge --info Portage 2.1.6.4 (default/linux/amd64/2008.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.27-gentoo-r7 x86_64) ================================================================= System uname: Linux-2.6.27-gentoo-r7-x86_64-AMD_Phenom-tm-_9750_Quad-Core_Processor-with-glibc2.2.5 Timestamp of tree: Fri, 23 Jan 2009 04:35:01 +0000 app-shells/bash: 3.2_p39 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.4.4-r13, 2.5.2-r7 dev-python/pycrypto: 2.0.1-r6 dev-util/cmake: 2.4.6-r1 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.csse.rose-hulman.edu/gentoo/" LDFLAGS="-Wl,-O1" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X a52 aac aalib acl acpi afs aim alsa amd64 apache2 atm avahi bash-completion berkdb bidi bluetooth bzip2 cairo caps cddb cdparanoia cdr cgi clamav cli cracklib crypt css cups curl curlwrappers cvs cxx dbus dga directfb doc dri dv dvb dvd dvdr dvdread emacs encode examples exif expat fastcgi fbcon ffmpeg firefox flac fontconfig foomaticdb fortran ftp gd gdbm geoip gif gimp gnome gphoto2 gpm gps graphviz gstreamer gtk gtkhtml gzip hal hddtemp iconv icq icu idn ieee1394 imagemagick imap imlib ipod ipv6 isdnlog jabber jack java javascript joystick jpeg jpeg2k kde kerberos krb4 lame ldap libcaca libnotify libwww lirc lm_sensors lzo mad maildir matroska mbox midi mime mmap mmx motif mozilla mp3 mpeg mplayer msn mudflap multilib mysql mysqli ncurses netboot nls nntp nocd nptl nptlonly nsplugin odbc offensive ogg openal opengl openmp oscar pam pcre pda pdf perl php png posix ppds pppd profile python qt3 qt4 quicktime radius raw rdesktop readline reflection rss ruby samba sasl scanner sdl session slang smp snmp soap sockets socks5 speex spell spl sqlite sqlite3 sse sse2 ssl subversion suid svg sysfs tcl tcpd theora threads tidy tiff tk tokenizer truetype unicode usb v4l v4l2 vcd videos vnc vorbis wavpack wifi wmf wxwindows x264 xattr xine xinerama xml xorg xscreensaver xulrunner xv xvid yahoo zeroconf zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci 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 mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="fbdev glint i810 intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa vga via vmware voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 179484 [details] Update gdm ebuild to not require lwp on amd64 As far as I can tell, openafs provides (via static linking) all the required libraries from lwp. This ebuild removes the requirement for sys-libs/lwp from gdm for amd64 systems (the only type of machine I was able to test on). Using the new ebuild, gdm still compiles and runs fine with the USE flags listed from my emerge --info posted above. Note that I also tested the gdm-2.20.7 ebuild in the main Portage tree, building it using emerge --nodeps after I uninstalled lwp. It still worked just fine, suggesting the gdm dependency on lwp is not actually a dependency.
*** Bug 263002 has been marked as a duplicate of this bug. ***
Maybe a first step would be to fix the gdm dependancies ?
*** Bug 270365 has been marked as a duplicate of this bug. ***
*** Bug 275297 has been marked as a duplicate of this bug. ***
changing gdm dependencies is looking at the problem from the wrong end. lwp and openafs should not have file-collision to begin with, at least not without a blocker dependency.
(In reply to comment #14) > changing gdm dependencies is looking at the problem from the wrong end. lwp and > openafs should not have file-collision to begin with, at least not without a > blocker dependency. Adding a blocker dependency would certainly eliminate the collision, but would in my opinion be inappropriate: the majority of both packages' users never even use liblwp.a. Then again, I would be cautious about removing this file from the installation, as there are a number of packages in portage (and probably some outside portage as well) depending on openafs. I currently have no idea about how and whether these use liblwp.a specifically, though. One could also argue that coda's liblwp.a is only used by coda components, and that it seems safer to change this library's name in a known set of related packages than in one (openafs) used by third-party applications. Again, adding a blocker seems like a definitive and easy solution, but personally I would not want to needlessly prevent people from having both packages installed concurrently.
'emerge gnome' tries to install lwp, which complains about file collision with openafs. Any hint?
(In reply to comment #16) > 'emerge gnome' tries to install lwp, which complains about file collision with > openafs. Any hint? > Juergen: you can get it installed by doing emerge -1 liblwp, then removing liblwp.a from /usr/lib and installing openafs (emerge -1 openafs). After that you should be able to install Gnome. However, be careful - this solution has not been tested other than by me, and that was a long time ago :)
(In reply to comment #17) > Juergen: you can get it installed by doing emerge -1 liblwp, then removing > liblwp.a from /usr/lib and installing openafs (emerge -1 openafs). After that > you should be able to install Gnome. However, be careful - this solution has > not been tested other than by me, and that was a long time ago :) Actually: the other way around would be better. build openafs and move liblwp.a after it builds to something like libopenafs_lwp.a openafs is not supposed to be a provider for lwp, and it seems to include the library for its own re-use (but since it is a static library it is only needed by anything at build time... and I know of 0 other packages that leverage the liblwp.a from openafs) there are however plenty of packages using liblwp from the lwp package(such as gnome etc) The real issue here is that openafs shouldn't be installing liblwp.a or any other pieces of lwp
(In reply to comment #18) > > openafs is not supposed to be a provider for lwp, and it seems to include the > library for its own re-use (but since it is a static library it is only needed > by anything at build time... and I know of 0 other packages that leverage the > liblwp.a from openafs) So is this an upstream issue then? > > there are however plenty of packages using liblwp from the lwp package(such as > gnome etc) > > The real issue here is that openafs shouldn't be installing liblwp.a or any > other pieces of lwp > Can we get around the issue by just not installing openafs' packaged liblwp.a (and possibly including a dependency from openafs to lwp, to replace the library for other applications)?
(In reply to comment #19) > So is this an upstream issue then? I think that would be the correct classification. If openafs would intend to be leveraged as a liblwp provider they would most surely include a dynamic library. However openafs doesn't see much activity so getting them to fix could take a very long time... > Can we get around the issue by just not installing openafs' packaged liblwp.a > (and possibly including a dependency from openafs to lwp, to replace the > library for other applications)? I think the best solution for Gentoo is to adjust the openafs ebuild to either install openafs' liblwp.a in a different place or not at all.
Do we have an patch, which is doing the solution of comment 18 or 20? Regards Juergen
Created attachment 209894 [details] patch for openafs-1.4.11.ebuild to avoid file collision Wath do you think about the attached file?
(In reply to comment #22) > Created an attachment (id=209894) [details] > patch for openafs-1.4.11.ebuild to avoid file collision > > Wath do you think about the attached file? Works for me.
Created attachment 217728 [details] /usr/local/portage/net-fs/openafs/openafs-1.4.11.ebuild
My patch from comment #22 does no more work. If I use the ebuild from comment #24 which contains this patch, /usr/lib/liblwp.a is no more renamed to /usr/lib/libopenafs_lwp.a. So 'emerge sys-libs/lwp' complains about existing /usr/lib64/liblwp.a, if openafs is emerged first, or 'emerge openafs' complains about /usr/lib64/liblwp.a, if sys-libs/lwp is emerged first. Any hint is appreciated.
Created attachment 217732 [details] openafs-1.4.11.ebuild which works again for me
openafs-1.4.12.1 ebuild disables all lwp installed files
