Make Delta an official Debian package

[inducer]

https://packages.debian.org/buster/delta

Rename maybe? delta-diff? delta-git?

[dandavison]

Thanks! Will it work for me to use git-delta as the package name, and for the package to continue to install an executable named delta? This is what I am doing for other platforms/package repositories (Homebrew, crates.io, AUR).

[inducer]

Debian policy suggests that there's a binary in the package that matches the package name. So in thinking of potentially getting delta into the Debian archive itself, it'd be good to pick a name that can stick. (So maybe name the binary git-delta?)

At the same time, naming it git-anything kind of obscures the fact that it's a useful diff tool in its own right.

Ah, naming. One of the three difficult things in CS. :)

[dandavison]

Do you know if it would be acceptable for the Debian package to install a symlink named git-delta and also install an executable named delta? I don't think I want to change the name of the executable; I may be wrong but I don't think the incumbent delta package is widely used or currently maintained.

[inducer]

That might work, but I'm no expert on Debian policy. :)

[valpackett]

We have that delta in FreeBSD Ports as well. I agree that it doesn't seem widely used, and we can do the

use git-delta as the package name, and for the package to continue to install an executable named delta

thing just fine, but it's unfortunate that the names won't match.

[tmccombs]

Due to this, it is necessary to hold the package after installation. Otherwise when I update, it installs the debian "delta" package and removes the git delta package.

[ronjouch]

By the way, since Ubuntu inherits Debian packages, this affects Ubuntu users too: https://packages.ubuntu.com/search?searchon=names&suite=all&section=all&keywords=delta

[dandavison]

Thanks, I'm still thinking about this and do want to get it sorted out. Relevant facts as I understand them are

• The package is currently named delta in Debian/Ubuntu package repositories, which simply does not work due to an existing package.
• I have named it git-delta in my personal Homebrew tap, and Crates.io.
• However, I'm not 100% comfortable with that since delta is useful on non-git diff input and support is now being contributed for improved unified diff handling (Support unified diff format #56)
• There is a public homebrew formula but it has not been advertised yet due to the bug Broken on macOS Catalina? #24 affecting Rust projects on Homebrew for MacOS Catalina.

Possibilities are

• Rename the package git-delta on all package repositories
• Choose a new package name that is neither delta, nor git-delta. @dawidd6 will it be OK to change the public Homebrew formula name if we want to?
• For example the package name could be delta-pager. It would then not be too surprising for a package with such a name to install an executable named delta. delta-pager is somewhat googleable but it is competing with an airline to some extent.
• Or change the package name and executable name to something new and the same as each other.

[dawidd6]

@dawidd6 will it be OK to change the public Homebrew formula name if we want to?

Sure thing, take a look at this recent PR how the process of renaming looks: Homebrew/homebrew-core#47011

[dandavison]

I've renamed the *.deb files as git-delta-*.deb: https://github.com/dandavison/delta/releases/tag/0.0.15. Is anyone able to advise on next steps for getting it into public package repositories?

[inducer]

Thanks for changing the package name! In terms of getting the package into Debian proper, https://mentors.debian.net/sponsors might be a start.

[FranklinYu]

In terms of getting the package into Debian proper

FYI this will be tracked in bug 944028.

Do we want to create a new issue in this repository to track it? So that we can have follow-up actions (such as ReadMe update).

[dandavison]

Thanks @FranklinYu.

Reopening with new issue name: "Make Delta an official Debian package"

[jubalh]

We at openSUSE have the same problem. Together with a file name conflict and not only package name conflict.
See https://build.opensuse.org/request/show/841782

Even though delta (delta.tigris.org) might not be active anymore. I think it would just be easier to just rename this (newer projects) binary. It would save trouble for several distros now. And it has less chance to confuse (older) users.

[dandavison]

Even though delta (delta.tigris.org) might not be active anymore. I think it would just be easier to just rename this (newer projects) binary. It would save trouble for several distros now. And it has less chance to confuse (older) users.

@jubalh Thanks very much for your work on openSUSE. I'm not sure I agree with your cost-benefit analysis. Delta already has many users, using many combinations of OSs and distros and package managers, and all of those people have the executable name in their git config, as well as shell utilities, aliases, etc. Delta is also used by other projects (e.g. git-fuzzy, lazygit, sad, forgit). Changing the executable name would be extremely disruptive to all those users. So I would ask -- do you definitely think that the benefits of renaming the project at this stage outweigh the costs? It is a shame that this is causing problems with Debian. Does openSUSE have more flexibility than Debian here? I do want to find solutions, so if distros need to install it under a different executable name I can add content to the README alerting people to the possibility that they may be in that situation.

Honestly, I don't think it's a reasonable expectation for tool authors to come up with, early on in the development of their project, a name that is globally unique across human history and cultures! Indeed, that's not the approach we take to globally unique identifiers elsewhere in modern computing. And on a practical level it's not clear how to test candidate names for uniqueness with respect to the distros in all human societies that might want to package the tool. However, I'll probably be more careful about naming my future projects :)

[allisonrandal]

Honestly, I don't think it's a reasonable expectation for tool authors to come up with, early on in the development of their project, a name that is globally unique across human history and cultures!

Distro packagers don't expect the upstream projects to pick globally unique names, really, very few projects think about how to make the work of packaging easier. So, thank you for being considerate about it! The requirement for a unique package name within each distro is an unavoidable consequence of the way most distro packaging systems work, and the requirement for a unique binary name is necessary for the way Linux/Unix does path lookups for executables. As distro packagers, we're very used to needing to make a few minor patches when we bring packages into the complete integrated system, it's kind of unavoidable when you're trying to make 50,000+ open source projects work well together.

For getting delta into Debian (and Ubuntu), your best path is to reach out to the Debian Rust Packaging Team, they'll have all the best style tips for Rust packages in Debian:

https://wiki.debian.org/Teams/RustPackaging

[dandavison]

@allisonrandal thanks for that. I'll contact the Debian Rust packaging team. Is my understanding here correct?

the requirement for a unique binary name is necessary for the way Linux/Unix does path lookups for executables.

That's true, in that we cannot have both installed simultaneously. But packages with distinct names installing a same-named binary can both be present in the package repository, in principle, and in practice: Delta is available in Arch Linux, Cargo, HomeBrew, MacPorts, Fedora dnf, FreeBSD pkg, Nix, Void Linux, Windows Chocolatey and Windows Scoop. Please anyone correct me if I'm wrong but I believe that in all of those it is installed with the binary name "delta", and I know that in some of those (e.g. HomeBrew, not sure which others) it is not the only package installing a binary named "delta". I'm currently only aware of Debian having a hard requirement for globally unique binary names.

Distro packagers don't expect the upstream projects to pick globally unique names

I may not have understood what you're saying here. Debian and openSUSE have suggested to me that I rename. This is what I meant by an expectation to have a globally unique name at the outset, since renaming one's project later on is so undesirable.

[allisonrandal]

@allisonrandal thanks for that. I'll contact the Debian Rust packaging team. Is my understanding here correct?

Feel free to ping me if you still need a sponsor (that is, a Debian developer to upload your package) after you talk with the Debian Rust team.

the requirement for a unique binary name is necessary for the way Linux/Unix does path lookups for executables.

I'm currently only aware of Debian having a hard requirement for globally unique binary names.

We can't guarantee which packages users will install simultaneously, so it isn't safe to keep mutually incompatible packages actively installable. The worst case is when one package installs /usr/bin/delta, and then another package installs over the top of the same file. Not kind to users at all, and wreaks havoc with automated distro testing.

Debian does reclaim old names sometimes, but they think about it carefully. For example, the original decision on Node.js by the Debian Technical Committee (in 2011) was that the binary would have to be renamed to "nodejs", due to a pre-existing package for the LinuxNode project. But, later they decided to rename the LinuxNode package to ax25-node, and today Node.js installs the binary /usr/bin/node.

I may not have understood what you're saying here. Debian and openSUSE have suggested to me that I rename. This is what I meant by an expectation to have a globally unique name at the outset, since renaming one's project later on is so undesirable.

I'd say it's reasonable to require a name change within one distro, to fit the distro's policies. I'd even say it's reasonable to suggest that different Linux distros try to coordinate, so if they require a name change, they all require the same name change, instead of a bunch of confusingly different name changes. But, it is not reasonable to suggest that the upstream project should pick a different name, just because there happens to be a legacy package that used that name. Which isn't to say that distro packagers are always reasonable, but we try to be.

[valpackett]

We can't guarantee which packages users will install simultaneously

Does dpkg/apt not detect this kind of conflict at runtime?

FreeBSD pkg will just prompt me to remove git-delta if I want the other, old 'delta' thing:

% doas pkg install delta
All repositories are up to date.
Checking integrity... done (1 conflicting)
  - delta-2006.08.03_1 [FreeBSD] conflicts with git-delta-0.0.16_9 [installed] on /usr/local/bin/delta
Checking integrity... done (0 conflicting)
The following 2 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        git-delta: 0.0.16_9

New packages to be INSTALLED:
        delta: 2006.08.03_1 [FreeBSD]

[dandavison]

HomeBrew package formulae also create a graph of package conflicts which are similarly detected at install time.

conflicts_with "delta", because: "both install a `delta` binary"

https://github.com/dandavison/homebrew-core/blob/88cef9d0693f9c1de8a66af42405f3618a5813a7/Formula/git-delta.rb#L19

[allisonrandal]

Yes, Debian has a similar mechanism. But, I'm not saying it's technically impossible, I'm saying it's sane and reasonable not to allow any random package across the distro to do it willy-nilly, and to refer these kind of decisions up the chain to technical leadership. The decision that seems right locally for one package isn't always the best decision globally for the distro.

[FranklinYu]

Could someone remind me of the problem here? I checked the files of package delta on Debian and can’t find a binary called delta. I also tried installing the package and there’s no /usr/bin/delta or any delta on my $PATH. Am I missing something?

[tmccombs]

Debian policy suggests that there's a binary in the package that matches the package name.

And there is a package named delta, which apparently does not conform to that policy.

[SuperSandro2000]

Maybe this https://packages.debian.org/sid/amd64/sptk/filelist collides.

[Kr1ss-XD]

Oops no don't think so, but you reminded me to just search for the binary. Probably it's swap-cwm.

Anyways, I think it's quite disproportionate to require upstream developers to name their projects/binaries uniquely across all distros, as that seems like an impossible mission. Hence it should be up to the packagers to come up with solutions to remedy such conflicts.

Just my € 0.02

[FranklinYu]

swap-cwm was removed from Bullseye and Sid branch. Maybe its maintainer @jonassmedegaard can have a word here?

[jonassmedegaard]

Hi all - former package maintainer of swap-cwm here.

Yes, swap-cwm contained the binary "delta", and yes, swap-cwm is no longer in Debian: Even if unmaintained for years it worked just fine, but sadly had to go when Python 2.x was dropped: https://bugs.debian.org/961607

This project looks like a great tool!

[Susensio]

Is there any way to instal delta in Debian besides manually downloading deb file? I would like it to upgrade automatically

[jonassmedegaard]

I have now taken on the task of packaging delta officially for Debian.
Sorry, I cannot say when it will be done and you can simply do apt install git-delta - could be weeks or years, depending the obstacles that might pop up, and whether you need it for Debian unstable, testing, or stable.

You can follow progress here (and you can subscribe by email if you want): https://bugs.debian.org/944028

[dandavison]

That's great to hear, thanks @jonassmedegaard. Let me know whenever I can be of help in the process.

[jonassmedegaard]

I will file issues here when I identify stuff that might need your attention. Thanks!

[jaques-sam]

Could be a bottleneck but latest version depends on libc6 >= 2.34 which is not installed in Debian11 (bullseye)

git-delta : Depends: libc6 (>= 2.34) but 2.31-13+deb11u5 is to be installed

[nsoranzo]

@jaques-sam This is tracked in #1250 .

[tmccombs]

@jaques-sam I don't think that really blocks it becoming a debian package. As I understand it that is a depency of the deb package published on github, but if you build from source (as would be the case for a deb published as part of the official debian repositories) using an older version of libc it works ok.

Not that it really matters, because debian 11 is stable now, so they probably won't add a new package like delta. It would probably be debian 13 at the earliest.

[jonassmedegaard]

Correct on both points: Debian 13 is the earliest that can officially include this project, and official inclusion requires building from source in a Debian environment which will ensure correct libc linking.

[jonassmedegaard]

Delta as now (under package name git-delta) officially entered the "unstable" branche of Debian.
A developer view of packaging health towards eventual transitioning to the "stable" branch is here and a more user-oriented listing is here.

[dandavison]

Thanks very much @jonassmedegaard and everyone else who helped with this!

As is the case with many other distributions and package managers, the package name in Debian is git-delta and the executable is delta.

("git-delta" was perhaps not a great package name choice by me since the tool can be used to diff files, handle unified diff output, and handle grep output. However delta does use gitconfig for its configuration, which maybe makes the name a bit less inappropriate.)