Hi Jonathan, Thanks for considering my request.
On Mon, Feb 18, 2013 at 02:03:13AM -0800, Jonathan Nieder wrote: > Ideally these should be hard links to the same inode (as in the > default configuration upstream). We can't ship them that way because > there is no guarantee the two paths are even on the same filesystem, A quick look at the Debian policy suggests that hard links are valid in binary packages. I have not yet encoutered a case where /usr/bin and /usr/lib are on separate filesystems. Considering this as a valid case will break the hard link case. dpkg uses tar to extract packages. A quick example shows how this breaks: tar: ./linktest: Cannot hard link to `./usr/linktest': Invalid cross-device link tar: Exiting with failure status due to previous errors On the bright side I believe that symbolic links would work as well here. The git package already employs them for a number of other binaries even though at present none of them cross directories. Many other packages use this technique as well: find /usr/bin -type l | xargs ls -l | grep ' -> \.\./lib/' (Hint if your system lacks example packages: ghc, iceweasel, llvm-3.1, pypy, swi-prolog-nox) We can conclude that the soft links are proven to work. > but postinst could replace one copy with a hardlink to the other when > the system configuration allows. I would not like to see a postinst trick here. It would keep wasting download bandwidth and mirror space. Getting it right seems hard as well. I'd rather tag this issue wontfix than resort to such a trick. Summary: From my point of view symbolic links are a clear winner here. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
