Retire debian packaging

[vilmibm]

As gh has appeared in Debian Sid, I think it would be prudent to sunset our Debian packaging. This packaging is a source of hosting headaches for us as well as a steady stream of issues (notably around key management).

As prerequisites for this, however, I suggest we:

• Provide a simple, non-sudo install script that can detect architecture and download a binary release
• Write up documentation on how to make use of the Sid package on Debian systems

I'm definitely interested in feedback on this. I'll leave needs-triage so it gets picked up in the next triage meeting.

[mislav]

Agreed that we could stop publishing our Debian package. However, we would still have to continue publishing our Ubuntu package, right? And we have to improve our GPG key management there anyway (for instance, what happens when the current key expires?). With that in mind, will we have tangible gains by dropping Debian?

• Provide a simple, non-sudo install script that can detect architecture and download a binary release

That would be great. When that gh self-detects that it's out of date, however, how would we suggest to our users that they upgrade?

[vilmibm]

However, we would still have to continue publishing our Ubuntu package, right

No, Ubuntu users can install packages from a Debian repository. As it is, we package a single debian repository and then just mark it as available for every extant Ubuntu distro. There's no actual difference in the package.

And we have to improve our GPG key management there anyway (for instance, what happens when the current key expires?).

We would still need to deal with that unless we drop RPM packaging also (which I am not opposed to but haven't checked to see if any major RPM distros package us)

When that gh self-detects that it's out of date, however, how would we suggest to our users that they upgrade?

We could suggest that they re-run the script (or offer to download an asset from a release ourselves). I recognize I'm essentially describing the upgrade command I've been opposed to in the past but my sentiments have changed.

[mislav]

However, we would still have to continue publishing our Ubuntu package, right

No, Ubuntu users can install packages from a Debian repository.

Will we then suggesting that Ubuntu users add the Debian Sid package repository to their sources to get access to gh? Is that kosher in Ubuntu world?

[vilmibm]

It's not uncommon to do that--also, I noticed that gh is already installable by default via apt in Ubuntu 22.04, so users on the current LTS wouldn't need to do anything to have gh be available. It's not a super recent version, but it's not ancient either.

[Xiphoseer]

From a user perspective, it would be nice to have the custom apt repository around until the stable release of Debian 12 (Bookworm), which should be sometime in the summer of next year, i.e. 2023.

Edit to clarify: bookworm is the first release that has a version of gh while stable is what the Debian Security Team tracks.

[kewisch]

Have you considered switching to container technology such as snaps? This could potentially solve a few issues around being distro and distro version agnostic.

[Spurlos]

Snaps isn't a good solution in case one would like to use gh as a tool in a stripped down linux distro such as Alpine, for example in a CI\CD automation.

[elibarzilay]

Dumping it in favor of "whatever comes with Ubuntu" is a bad idea. It works fine for "stuff that is generally stable so I don't care about it's freshness", and for stuff that you do care about it's nice to have an option that is fresh, yet works via the system packages. Here's a relevant example.

(And just in case the irony in the above is missed: dumping it in favor of "whatever comes with Debian", is a worse idea. (And this is not criticizing Debian.))

[xroche]

Provide a simple, non-sudo install script that can detect architecture and download a binary release

Replacing a common solution that has proven to be reliable (ie. apt with authenticated cryptographic key) by yet-another dedicated script is not enhancing the developer's experience I'm afraid. If every single tool comes with its own way of install, we are basically going back twenty years in time.

[mislav]

so users on the current LTS wouldn't need to do anything to have gh be available. It's not a super recent version, but it's not ancient either.

I think that the main problem with telling our users to install from official Debian or Ubuntu repositories is that, with our 2-week release cadence, the version of gh that they will get from their distro will always be out of date from our own. Then, those users will come to us for advice on how to install the actual latest version to get access to the latest feature or the latest fix. At that point, we could give them an installer script that manually fetches a *.deb file from our Releases, but how would they continue upgrading after that? A manually installed deb cannot upgrade, and we don't have a self-upgrader in place either.

It feels to me that continuing to publish our package repository offers users the best experience to stay up-to-date, provided that we solve the long-term question of refreshing the GPG key when it expires in the future. For example, we might be able to distribute public key updates via a separate deb package. Related: https://github.com/cli/cli/pull/5894

Have you considered switching to container technology such as snaps?

Yes, and it's not great as it stands right now: https://github.com/casperdcl/cli/issues/7