On Thu, Nov 12, 2015 at 10:50 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote: > On 11/12/2015 04:46 PM, Ralf Corsepius wrote: >> >> On 11/12/2015 04:36 PM, Nico Kadel-Garcia wrote: >>> >>> On Thu, Nov 12, 2015 at 4:11 AM, Jonathan Dieter <jdieter@xxxxxxxxx> >>> wrote: >>>> >>>> I'm reviewing nacl-binutils (https://bugzilla.redhat.com/show_bug.cgi?i >>>> d=1270355), which has hard links from /usr/x86_64-nacl/* to >>>> /usr/bin/x86_64-nacl-*. According to https://fedoraproject.org/wiki/Pa >>>> ckaging_Cross_Compiling_Toolchains, these should be symlinks, and >>>> rpmlint complains about cross-directory-hard-links. Is there any >>>> reason to convert these to symlinks or can we just leave them as hard >>>> links? >>>> >>>> Thanks, >>>> Jonathan >>> >>> >>> Thereis is, generally, no good excuse for a hardlink in an RPM. The >>> symlinks help indicate where the component actually resides, >> >> Things are not so clear as you think. >> >> May-by are in a position to tell where a cross-gcc|as|ar|ld recides? >> >> Though I have been an active contributor/maintainer to binutils and gcc >> for ca. a decade, I am not. The different locations are different views >> at identical binaries, aiming at different use-cases. >> >> Also, these links exist for very long times (>> 15 years) and have >> never, ever been a problem. > > > FWIW: Even on Debian, these are hardlinks. Yowch. That's... potentially quite nasty, or confusing, for reasons I've already described. And just because an installer or software compiler uses them, doesn't mean that a package manager (such as RPM) has to follow them. On review, there are a number of other packages that do use this sort of trick. "git", for example, links its binaries with hardlinks and relies on the name used to call the binary to be deduced for distinct behavior. I personally think using hardlinks for that is is silly as heck. but it does profoundly simplify using alternative root installation directories for rpm. The difficulty comes when modifying a local binary or configuration file that is hardlinked. It can be much more awkward to deduce where a hardlink points to: you have to search the filesystem by inode, or guess based on the filename and look for that. And certain editing editors or file copying procedures handline them rather differently, others will not: "cp -a" or "rsync -a" of a symlink will copy the symlink, not the target of it. "cp -a" of a hardlink will copy in top of the hardlink and change both targets, "rsync -a" will simply break the hardlink unless you use "rsync -aH" and include both previously linked files. -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
