[Fedora-packaging] For a cross-compiling toolchain, does it matter if /usr/bin/* links are symbolic or hard?

[Nico Kadel-Garcia]

On Thu, Nov 12, 2015 at 10:50 AM, Ralf Corsepius <rc040203 at freenet.de> 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 at lesbg.com>
>>> 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.