Aurelien Jarno <[EMAIL PROTECTED]> writes: > severity 367962 wishlist > thanks > > Goswin Brederlow wrote: >> Package: libc6 >> Version: 2.3.6-7 >> Severity: normal >> Hi, >> Currently the libc6 package on amd64 ships a symlink from /lib64 to >> /lib (and /usr/lib64). While the symlink is needed for things to work >> shipping it in the data.tar.gz makes it impossible for any package to >> put files into /lib64 or /usr/lib64 (as specified by FHS): >> If any package does so the next time libc6 gets updated you get an >> error similar to: >> dpkg: error processing foo1-1.0.deb (--install): >> trying to overwrite `/foo', which is also in package foo2 >> Instead of shipping the symlinks I suggest creating them in the >> preinst (if they don't exist) and shipping at least one file >> (/lib64/ld-2.3.2.so comes to mind) in /lib64 and /usr/lib64 to prevent >> dpkg from removing the links on updates. >> Why would we want this? >> With that change packages can be patched (or un-patched) to use the >> FHS compliant lib64 dirs. Libraries and plugins are then in a >> different directory than on i386 alowing for automatic conversion of >> amd64 packages to an i386 based bi-arch system. >> Also if enough packages get changed to /lib64 the symlinks could be >> droped and bugs filed against the remaining packages. Updating to a >> non symlinks way might be tricky but at least new installs would get >> the right dirs. >> > > I don't really understand here. When I tried to swap the directory and > the symlink, I have been told, that we don't have to do that, as
Swaping around wouldn't have worked since then libc6 would be uninstallable if any package has a file in /lib or /usr/lib. Using only /lib64 and /usr/lib64 would break too many existing packages so that isn't an option either. For now the only option is to not ship a symlink (be that lib -> lib64 or lib64 -> lib) but still create one in preinst. > Debian will never be compliant with the FHS. So why do you wan't to be > FHS compliant now? The system (64 bit only) as such is compliant since libc6 provides the link. Each package is not since they dump 64bit libraries in /lib and /usr/lib. My intention is to seperate out 32bit stuff in lib and 64bit stuff in lib64 so that they comply with the FHS for each seperate package and can possibly be resorted into multiarch dirs by a conversion script. In this case the right thing to do is also the more helpfull one. But we will never be able to split lib and lib64 dirs on the filesystem if packages don't use them in the data.tar.gz first. At work we sell Debian based clusters with a 32/64bit biarch setup with automaticaly converted sarge packages but since both use /lib and /usr/lib anything with plugins can't work in both bit sizes. If packages can use /lib64 and /usr/lib64 I can send in patches for all of them and get them working for etch. Also upstream sources are using lib64 more and more and Debian has to patch it back to lib again. Every time some package upstream changes to lib64 the libc6 package becomes unupgradable because it tries to overwrite some packages /lib64 or /usr/lib64 directory with a symlink and the other package has to be fixed. I think 5 or 6 users have already encountered such a bug this year. I would have liked to go directly to multiarch dirs but resistance from people, including the glibc and gcc teams, made that unlikely to happen even partialy for etch. Using lib64 now will make it much easier to change the dir to the multiarch name later if it is done with a proper abstraction (put the libdir in variable so only one place needs changing). Multiarch won't come in one big wave so now I'm trying to do it in many little steps. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]