Binary file rename: any preference?

[paride]

Hi, Debian maintainer of the bat package here.

As the bat binary name is already taken in Debian by the bacula-console-qt package, I'll have to rename the bat binary from this project and its manpage. At some point change will affect Ubuntu too. I read in #164 that you don't intend to rename it upstream, however: do you have any preference for the alternative name? I was thinking of batcat.

The same happened with https://github.com/sharkdp/fd/, unfortunately. While the rename itself is not problematic, the manpage won't be consistent with the new tool's name, so the solution is quite far from being ideal. Parametrizing the tool name would produce a better result.

[eth-p]

I'm 100% for parameterizing the name and docs for bat to make packaging easier on distro package maintainers.

Based on a quick look at the CI scripts, the file names for the manpage and binary look like they are capable of being parameterized. The contents of the manpage do not, however.

We would probably need some cross-platform preprocessor or template generator to keep building consistent between Windows and Linux. I'm not sure, but maybe there's something already built into Cargo to achieve this already?

If that's overkill, I can always hack up a Bash/sed and PowerShell script to do a simple find and replace until we have the need for something more complex.

@sharkdp, your opinion?

[sharkdp]

@paride Thank you very much for bringing this discussion here and for maintaining the Debian package!

As the bat binary name is already taken in Debian by the bacula-console-qt package, I'll have to rename the bat binary from this project and its manpage.

Oh, that is unfortunate 🙁.

Based on a quick look at the CI scripts, the file names for the manpage and binary look like they are capable of being parameterized. The contents of the manpage do not, however.

There are also command-line variables named BAT_* and the config files/cache files which are currently placed in ~/.config/bat and ~/.cache/bat. The whole README would also be inconsistent with the Debian/Ubuntu versions. Not to mention that the package and the binary is called bat in the official repositories for Alpine Linux, Arch Linux, Fedora, Gentoo, Void Linux, FreeBSD, openSUSE, Homebrew, Scoop, Chocolatey and on crates.io.

To be honest, I still don't quite understand why the Debian/Ubuntu policies are so strict in this regard. I know I've asked this before, but would it be so bad for users to mark the two packages as conflicting?

I obviously knew that there was a high chance of clashes when I initially named this bat, but somehow I really like the name. After what happened with fd, I even checked that bat was free in most package managers (but I forgot to check packages with other names, providing binaries named bat). I would never try to deliberately "hijack" an existing name, but the space for good and concise program/library/package names is kind of limited. And somehow it feels like the Debian/Ubuntu policy does not "scale" well into the future in this regard.

[paride]

Hi @sharkdp,

Based on a quick look at the CI scripts, the file names for the manpage and binary look like they are capable of being parameterized. The contents of the manpage do not, however.

I think it would be enough to change the two USAGE lines in the manpage and the manpage title (see below: I think there is no need to rename the project, but just the binary). A preprocessing step should allow this (e.g. sed s/{{binname}}/batcat/), but I can see how this is ugly.

There are also command-line variables named BAT_* and the config files/cache files which are currently placed in ~/.config/bat and ~/.cache/bat. The whole README would also be inconsistent with the Debian/Ubuntu versions.

Personally I'd leave these are they are. The project is still named "bat" after all, so the config files and references to the project are fine with using bat/BAT in my opinion.

Not to mention that the package and the binary is called bat in the official repositories for Alpine Linux, Arch Linux, Fedora, Gentoo, Void Linux, FreeBSD, openSUSE, Homebrew, Scoop, Chocolatey and on crates.io.

I know, this is very unfortunate.

To be honest, I still don't quite understand why the Debian/Ubuntu policies are so strict in this regard. I know I've asked this before, but would it be so bad for users to mark the two packages as conflicting?

There at least a couple of good points in favor of this policy:

• Marking the packages as conflicting prevents the user to install both of them at the same time (obviously). This could be fine with niche packages, but annoying with general-purpose packages like bat.
• Consistency. If the two packages are "just" marked as conflicting (without any rename) you may end up having different Debian systems where the same command does different things. This would be annoying or even dangerous (think of running a script or an Ansible playbook which calls the wrong tool). The current policy ensures that in a given Debian release the bat command always does one thing.

This said, I agree with you: the policy is probably too strict and should give more freedom on this point to the package maintainer. Thing is: the policy isn't going to change, we have to live with it.

[sharkdp]

@paride Thank you for taking the time to explain this in detail!

Consistency. If the two packages are "just" marked as conflicting (without any rename) you may end up having different Debian systems where the same command does different things. This would be annoying or even dangerous (think of running a script or an Ansible playbook which calls the wrong tool). The current policy ensures that in a given Debian release the bat command always does one thing.

I hadn't thought of this.

If there is no way around this, I think batcat is a decent choice. I can't come up with anything else right now.

I think it would be enough to change the two USAGE lines in the manpage and the manpage title (see below: I think there is no need to rename the project, but just the binary). A preprocessing step should allow this (e.g. sed s/{{binname}}/batcat/), but I can see how this is ugly.

Okay, let's work on the tooling in #659 and discuss the binary name in this ticket.

[paride]

As it seems that we're both +1 for batcat and that no other option has been proposed let's settle with it and move to #659 for the tooling. Thanks a lot for your feedback!

[sharkdp]

It looks like the bat binary didn't have to be renamed after all (according to the "list of files")?

https://packages.debian.org/sid/bat
https://packages.ubuntu.com/eoan/bat

[paride]

It needs to be, the current package violates the Debian policy. See this bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934850

It's a severity: Serious bug, meaning that the current version of the package won't migrate to testing and thus won't be part of the next Debian stable release.

[sharkdp]

Ok, thank you. I just thought it was interesting that Ubuntu stable actually has a bat package with a /usr/bin/bat binary. Won't this cause regressions for Ubuntu users?

[bdrewery]

@paride It makes no sense a package named "bat" has a binary named "batcat". Suggest renaming package to "batcat", or letting this package own "bat". Think intuitive for users.

[divinity76]

I too found it confusing that the package is named "bat" but the binary is named "batcat", IMO the package should also be named batcat