Fd: Dependencies update: Cargo.toml not updated

[paride]

I see that 59c9901cde03bfde2715a07e0c4a8ffc7b2da9c6 updates some dependencies, but Cargo.toml does not reflect these changes: it still lists the old dependencies.

Once this is fixed, may I ask you if you intend to tag a new release? I'm planning to maintain the fd-find Debian package, and with the updated dependencies it will be way easier. Thank you!

[sharkdp]

Thank you for the feedback.

Yes, Cargo.lock was updated via cargo update, but no changes were made to the version boundaries in Cargo.toml (which is perfectly fine, I believe).

As far as I can see, all dependencies are up-to-date? Are there any particular version-updates that you have in mind?

[paride]

@sharkdp You are right, and you can expect to see fd Debian packaged shortly. Unfortunately I will have to rename the binary (and the manpage) to fdfind, as /usr/bin/fd is alredy taken by another package.

About the dependencies: there is a thing I have to ask you. It doesn't seem that you are using the wrap_help feature of clap, but you still depend on it. This is a bit troublesome, as wrap_help depends on term_size, which does have some outdated dependencies. Could you consider droppping the dependency on wrap_help, if you are not planning to use it?

Thanks!

[paride]

Once again I think I have misunderstood how the dependency system works. You have to excuse me: I don't actually program in Rust, I'm just trying to do the packaging work.

So wrap_help does get used. I managed to compile fd-find without it, but I'm not sure I want to release the package like this. Let's see if I can get wrap_help packaged.

[sharkdp]

Once again I think I have misunderstood how the dependency system works. You have to excuse me: I don't actually program in Rust, I'm just trying to do the packaging work.

In cargo, features are a way to change/configure the behavior of a library at compile time (here, wrap_help enables some code in clap that formats the --help text of fd in a different way). Features may pull in other dependencies (like term_size in this case).

So wrap_help does get used. I managed to compile fd-find without it, but I'm not sure I want to release the package like this.

Yes. While wrap_help is not really something that absolutely needs to be enabled to make fd work properly, I wouldn't want to disable it just for packaging reasons.

Let's see if I can get wrap_help packaged.

Great. Let us know if you need help with anything.

... and you can expect to see fd Debian packaged shortly

That would be awesome :heart_eyes:

Unfortunately I will have to rename the binary (and the manpage) to fdfind, as /usr/bin/fd is alredy taken by another package.

Hm, that's a real pity. Is there no other solution? Couldn't the two packages be marked as "conflicting"?

[paride]

Hm, that's a real pity. Is there no other solution? Couldn't the two packages be marked as "conflicting"?

The Debian Policy would demand a rename [0], but I will discuss with the other maintainers of Rust packages, maybe we can try to handle it with a package conflict. I would also prefer to avoid the rename.

[0] https://www.debian.org/doc/debian-policy/ch-files.html#binaries

[sharkdp]

The fd binary is called fd in the official packages for Fedora, Arch Linux, Gentoo, openSUSE and Homebrew (I don't know of any package that renames the binary - Fedora calls the package "fd-find", but the binary is named fd). It would be fantastic if Debian could follow suit :smiley:

Again, let us know if we can help with anything in this process.

I'm going to close this ticket, but feel free to comment here if anything is missing from our side.

[paride]

@sharkdp I will do my best to avoid the rename. There is probably an intermediate solution: providing a fd-find-base package that install the binary as /usr/bin/fd-find, and a fd-find package that provides a symlink /usr/bin/fd -> /usr/bin/fd-find. This package will then conflict with the other package providing /usr/bin/fd. I hope there will be consensus on this solution.

[paride]

@sharkdp We had a discussion in the debian-devel mailing list and a rename will be neccessary, so in Debian this tool will be named fdfind. Not that I'm happy with the solution, but all the alternatives do have drawbacks too, and this is the most conservative choice.

[sharkdp]

@paride Ok, Thank you for trying!

I'm curious: What is the current status? Where can I follow discussions on this?

[paride]

@sharkdp There is a long thread starting with

https://lists.debian.org/debian-devel/2018/09/msg00034.html

where the issue of file name conflicts is discussed in general, and fd is named a few times. If you follow the thread you will see that there is no consensus in handling such issue differently from a rename. The package with the renamed binary is currently waiting in the "new packages" queue:

https://ftp-master.debian.org/new.html

waiting to be accepted into the distribution.

[sharkdp]

Thank you!