-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retire debian packaging #5941
Comments
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?
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? |
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.
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)
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 |
Will we then suggesting that Ubuntu users add the Debian Sid package repository to their sources to get access to |
It's not uncommon to do that--also, I noticed that |
From a user perspective, it would be nice to have the custom apt repository around until the Edit to clarify: |
Have you considered switching to container technology such as snaps? This could potentially solve a few issues around being distro and distro version agnostic. |
Snaps isn't a good solution in case one would like to use |
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.)) |
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. |
The apt repo for the gh cli is broken due to an expired GPG key: cli/cli#6175 They want to retire the debian packaging altogether cli/cli#5941 and this is the recommended "long term" solution cli/cli#6175 (comment). Adapted from cli/cli#6175 (comment) Fixes myoung34#236
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 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: #5894
Yes, and it's not great as it stands right now: casperdcl#7 |
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:
I'm definitely interested in feedback on this. I'll leave
needs-triage
so it gets picked up in the next triage meeting.The text was updated successfully, but these errors were encountered: