Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62896 - [util-linux] 2.34-1 collides with [hardlink] 0.3.0-2 on /usr/bin/hardlink

Attached to Project: Arch Linux
Opened by Pascal Ernster (hardfalcon) - Friday, 14 June 2019, 11:39 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 17 February 2021, 13:24 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Dave Reisner (falconindy)
Christian Hesse (eworm)
Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


util-linux 2.34-1, which was recently pushed to the testing repo, collides with hardlink 0.3.0-2 from the community repo, since both contain /usr/bin/hardlink.
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Wednesday, 17 February 2021, 13:24 GMT
Reason for closing:  Fixed
Additional comments about closing:  Worked around by removing from util-linux since 2.34-2

The next version of util-linux will instead include and replace the "hardlink" package implementation.
Comment by Christian Hesse (eworm) - Friday, 14 June 2019, 11:52 GMT
So we add provides and replaces for hardlink and drop the package when util-linux moves?
Comment by Christian Hesse (eworm) - Friday, 14 June 2019, 13:28 GMT
Looks like the programs differ. So just replacing is probably a bad idea. Any suggestion how to handle this?
Comment by Eli Schwartz (eschwartz) - Friday, 14 June 2019, 15:39 GMT
What functional differences are there? Is there any special reason to prefer one over the other?

Aside: the same issue exists for "rename", in that case the perl-rename package provides /usr/bin/perl-rename and I sort of wish it were the authoritative "rename" command. :p
Comment by Sébastien Luttringer (seblu) - Friday, 14 June 2019, 16:50 GMT
Both have the same purpose: merge files with same content/attributes using hardlinks.

The jak-linux-hardlink has more features (more file selection criteria, xattr support, keep the oldest, etc).

Looks like features (and command line syntax) of jak-linux-hardlink is a superset of karelzak-hardlink.
Until there is a better or equivalent set of feature, I think we should keep jak-linux-hardlink and disable karelzak-hardlink.
Comment by Michel Koss (MichelKoss1) - Friday, 14 June 2019, 20:35 GMT
Why you want to keep hobby tools not touched since 2014 at cost of util-linux goodies which are de facto standard in linux? If you don't want to drop the package then rename its binaries to something sensible an move on.
Comment by Sébastien Luttringer (seblu) - Friday, 14 June 2019, 23:27 GMT
I'm sorry:
- the latest release was 23th January 2019, see:;
- It's not an hobby tool. Even if it was, what's the point?
- Being part of util-linux doesn't make it linux standard.

Our current hardlink (from debian) is technically better that the new one (from Fedora) merged into util-linux. Take a look at the commit log.
I would always prefer better implementation for selection. That's why, even I would be happy to have one package less to maintain, I draw attention to this point.

Switching as is, will break things for our current hardlink users, like our code of the archive[1] which expect the -O behavior.

That remembered, I'm also fine with a more political decision of moving to hardlink@util-linux because hardlink:
- will be in base group, so commonly installed under Arch;
- may be synchronized among distribution in a near future by util-linux.

I would like to have more opinion of developers on this.

PS: I'm wondering why util-linux pick the one from fedora[2], instead of debian[3].

Comment by Eli Schwartz (eschwartz) - Saturday, 15 June 2019, 00:12 GMT
Meanwhile on pure age alone, Red Hat's "hardlink" was last modified in 2017.

@seblu, could you maybe ping upstream to update the main website, or did they only release the new version via Debian's packaging infrastructure???


I do not see what is so holy about util-linux. And something that is only available in the very latest bleeding edge version is hardly "goodies which are de facto standard in linux", it cannot be a standard if it doesn't work literally anywhere that has a util-linux more than 14 hours old.

> Looks like features (and command line syntax) of jak-linux-hardlink is a superset of karelzak-hardlink.

If Debian's "hardlink" is command-line compatible with the one recently merged into util-linux then I see no reason to ever use the latter. Disable it from util-linux, let people use pacman -F / pkgfile to find the program binary if they are really confused. Optionally follow up on the case, by requesting karelzak to delete the current implementation and replace it with the superior one -- then the so-called "de facto standard" and "common sense" will be in agreement once the next version is released. It makes sense to try -- if util-linux is open to distributing such a program in the first place, surely they are open to discussing which featureset to include.
Comment by Michel Koss (MichelKoss1) - Saturday, 15 June 2019, 09:02 GMT
@seblu Arch ships version from 2014. If you knew there is a newer one then why you didn't update it? The last version uses pcre2 by default for example

"will be in base group, so commonly installed under Arch"

This is a good point. If you decide to stick with separate hardlink then maybe move it to core? You have Developer status already...

"could you maybe ping upstream to update the main website, or did they only release the new version via Debian's packaging infrastructure???"

It's possible that salsa is the new upstream repo as author of hardlink is debian developer.
Comment by Pascal Ernster (hardfalcon) - Saturday, 15 June 2019, 10:15 GMT
@eschwartz: There is at least one parameter that both hardlink varieties use for different behavior, namely the "-f" parameter.

From the man page of jak-linux-hardlink:

-f or --respect-name
Only try to link files with the same (basename).

From the man page of karelzak-hardlink:

-f, --force
Force hardlinking across file systems.

@MichelKoss1: To be fair, the migration to pcre2 and the migration from <attr/xattr.h> to <sys/xattr.h> seem to be the only relevant changes in jak-linux-hardlink since version 0.3.0, all other changes in the git repo are of purely cosmetic nature.

Personally, I don't have any particular preference for either of both implementations. Although I had installed the package some time ago, I've never actually tested/used it.
Comment by Eli Schwartz (eschwartz) - Sunday, 16 June 2019, 02:40 GMT
Now I'm incredibly curious why one would want to try and fail to hardlink across filesystems.
Comment by Pascal Ernster (hardfalcon) - Sunday, 16 June 2019, 08:07 GMT
Maybe for a btrfs with multiple subvolumes which are mounted to different mount points?
Comment by Julian Andres Klode (juliank) - Sunday, 16 June 2019, 10:48 GMT
Hi there!

Sorry for not publishing 0.3.1 and 0.3.2 on the website, I forgot about that.

I opened to discuss the issue with util-linux folks, let's hope we can get to a reasonable conclusion.

Thanks for the analysis everyone, it's a bit sad they added a different `-f` since the time we forked CLI-option-name-wise (code was never shared, but I kept the CLI compatible), because that realistically means that the only way forward is to drop -f, so it behaves the same way (fails) no matter whether you expect it to force or respect names.
Comment by Eli Schwartz (eschwartz) - Monday, 17 June 2019, 12:08 GMT
Update: util-linux is looking into merging, and it's proposed that the next version of util-linux will have the final hardlink command that everyone can agree on.

I recommend that for now, we disable it in util-linux for one release, and stick to the additional package.

EDIT: I see when I pacman -Syu that that already happened early this morning.
Comment by Christian Hesse (eworm) - Monday, 17 June 2019, 15:20 GMT
Yes, I pushed an update without hardlink earlier today.
Do we want to keep this open until final solution?
Comment by Sébastien Luttringer (seblu) - Tuesday, 18 June 2019, 15:21 GMT
It's a pleasure to read the upstream reaction. Very constructive mind!

I think we should close, the issue is fixed.

Merging hardlink could be another topic when the upstream work will be completed (planned for 2.35 - 3/4 months).
Your call Christian.
Comment by Eli Schwartz (eschwartz) - Wednesday, 17 February 2021, 13:01 GMT
Reopening for status update:

util-linux hardlink in git master is now the same program from the hardlink package. The next version of util-linux should provide/conflict/replace "hardlink" in order to merge the two packages together.