For a cross-compiling toolchain, does it matter if /usr/bin/* links are symbolic or hard?
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
On 11/12/2015 10:11 AM, Jonathan Dieter 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?
IIRC, the only purpose of these "duplicate" binaries, is to support non-canonicalized and canonicalized style of invoking these binaries[1] (/usr/bin/$target-* vs. /usr/$target/bin/*). I am not sure, but AFAICT, it doesn't matter to the GNU-toolchain, whether these links are hardlinks or symlinks.
However, whether they are hardlinks or symlinks matters to rpm. GNU-toolchain packages using hardlinks will fail to install, if /usr/$target and /usr/bin are on different partitions [2].
I doubt this is an actual problem, because we already have several such packages in Fedora, and at least I do not recall anybody ever having complained about it (Probably nobody is putting /usr/bin and /usr/$target on separate partitions)
So, when being pedantic, one would have to enforce symlinks, but when being pragmatic, these hard links should not be much of a real world issue.
Ralf
[1] "canonicalized" == "target-tuple-prefixed" binaries, e.g. "$target-as", typically installed to /usr/bin/.
"non-canonicalized" == "non-target-tuple-prefixed" binaries. e.g. "as", typically installed to /usr/$target/bin/ar
[2] e.g. the mingw{32,64}- toolchains. When putting /usr/i686-w64-mingw32 or /usr/x86_64-w64-mingw32 on a separate partition, installing these toolchain's binutils/gccs will fail miserably.
On Thu, 2015-11-12 at 16:27 +0100, Ralf Corsepius wrote:
So, when being pedantic, one would have to enforce symlinks, but when being pragmatic, these hard links should not be much of a real world issue.
Thanks so much for the explanation. I've gone ahead and requested that the hardlinks be changed to symlinks, but made it clear that it's not a blocker.
Jonathan
On Thu, Nov 12, 2015 at 4:11 AM, Jonathan Dieter jdieter@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, and the relevant software package, and the target of the symlink is easy to discover. The other member of a set of hardlinks is nowhere so easily traced, and it becomes unclear if modifying one should modify both.
On 11/12/2015 04:36 PM, Nico Kadel-Garcia wrote:
On Thu, Nov 12, 2015 at 4:11 AM, Jonathan Dieter jdieter@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.
Ralf
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@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.
Ralf
On Thu, Nov 12, 2015 at 10:50 AM, Ralf Corsepius rc040203@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@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.
"NK" == Nico Kadel-Garcia nkadel@gmail.com writes:
NK> I personally think using hardlinks for that is is silly as heck. but NK> it does profoundly simplify using alternative root installation NK> directories for rpm.
Just a note that the packaging guidelines only weakly suggest that relative symlinks be used for this purpose, but do not require it. There's the potential for breakage there but Fedora does seem to cope. I do think rpmlint warns about absolute symlinks, though.
It may be worth a change to the guidelines to mandate or at least more strongly suggest relative symlinks in preference to absolute ones. I'm not really sure about that, though.
https://fedoraproject.org/wiki/Packaging:Guidelines#Symlinks
- J<
On Thu, 2015-11-12 at 10:36 -0500, Nico Kadel-Garcia wrote:
Thereis is, generally, no good excuse for a hardlink in an RPM. The symlinks help indicate where the component actually resides, and the relevant software package, and the target of the symlink is easy to discover. The other member of a set of hardlinks is nowhere so easily traced, and it becomes unclear if modifying one should modify both.
While I agree with you, it appears that it's standard procedure to use hardlinks rather than symlinks in this way for most (all?) of the cross-compiler toolchains in Fedora.
Ralf cited mingw and I checked a couple others, and every one of them uses hardlinks.
As mentioned in a reply to Ralf, I'm requesting that the packager change the hardlinks to symlinks, but not making it a blocker.
Jonathan
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Jonathan Dieter -
Nico Kadel-Garcia -
Ralf Corsepius