Arch Linux

So we add provides and replaces for hardlink and drop the package when util-linux moves?

Looks like the programs differ. So just replacing is probably a bad idea. Any suggestion how to handle this?

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

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.

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.

I'm sorry:
- the latest release was 23th January 2019, see: https://salsa.debian.org/jak/hardlink;
- 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].

[1] https://www.archlinux.org/packages/extra/any/archivetools/
[2] https://pagure.io/hardlink/blob/master/f/hardlink.c
[3] https://salsa.debian.org/jak/hardlink/blob/master/hardlink.c

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.

@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.

@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.

Now I'm incredibly curious why one would want to try and fail to hardlink across filesystems.

Maybe for a btrfs with multiple subvolumes which are mounted to different mount points?

Hi there!

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

I opened https://github.com/karelzak/util-linux/issues/808 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.

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.

Yes, I pushed an update without hardlink earlier today.
Do we want to keep this open until final solution?

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.

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.

https://github.com/karelzak/util-linux/commit/2180ecc81b5f7635adbe5412010642e15fa212d3