aristocratos
Drop snap packing from this repository
With regards to https://github.com/aristocratos/btop/pull/1261 I'd like to discuss whether we should drop snap packaging.
If I'm getting it right we have the packaging files and a CI job to build it, but we do not publish from this repo? (Is it done in tandem with the Github release?)
@kz6fittycent is the owner of the snap package so I expect they are the one to upload the package independently.
If the assumptions are right, I suggest we move the files transparently (by linking there from the README or issue tracker) to @kz6fittycent they can provide better support in terms of expertise.
Another solution would be to take over ownership of the snap and automate releases alongside the Github release (also this can also be managed "downstream" if we move the files), however I kind of rejected other attempts to add distribution specific files to this repository in the past and I'd like to keep it that way, since that would add additional maintenance burden and also these files are better kept in the hands of experts for the distribution.
I'm happy to here you comments about this (btw I'm not dying on that hill, if you like to keep it that way).
cc @aristocratos @kz6fittycent @brlin-tw
Found out that btop on all my machines (Ubuntu 20+) is delivered via APT, and thus outdated:
$kenyawest: ~ ❯ sudo apt-cache policy btop
btop:
Installed: 1.2.3-2
Candidate: 1.2.3-2
Version table:
*** 1.2.3-2 500
500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
100 /var/lib/dpkg/status
I thought of using Snap store to get new version, but seeing this issue, I am so confused...
Is there an option that Snap version could possibly become stale, too?
What do I do now? Rely on Snap, choose binary installation, or wait some time for this issue to resolve?
@deckstose
If I'm getting it right we have the packaging files and a CI job to build it, but we do not publish from this repo? (Is it done in tandem with the Github release?)
~~An integration is likely installed in the repository so that a build on the Snap Store is triggered whenever a push/tag event occurs.~~
Refer to the Webhooks settings page for more info if you have admin access to the repository.
If the assumptions are right, I suggest we move the files transparently (by linking there from the README or issue tracker) to @kz6fittycent they can provide better support in terms of expertise.
This would be troublesome as the aforementioned integration doesn't work the same when the software source and its packaging assets reside in separate repositories. For example, we will no longer be able to trigger builds from the source repo push events if we ever want to publish pre-release builds via the candidate/beta/edge channels.
From a snap packager's PoV, it would be ideal if the upstream could make the distribution their own, but I can understand the hesitance here.
Hi.
Several things. I am totally in favor of the snap being maintained by the upstream repo and team. It was my first proposal, but with the caveat to @aristocratos that I'd be happy to help by maintaining the snap to get more people using this amazing tool, that my initial PR be accepted as the first stepping stone to the project publishing the snap and maintaining it completely internally. I understand, as @brlin-tw stated, the reticence of the team to maintain the snap, but I would encourage the team to seriously consider taking it over.
From my perspective, there are several ideal reasons that the core development team should take over the snap entirely:
- They can control the release schedule and cadence for the entire stack of software
- They can better delineate between an issue with the application or the snap than can someone who only packages it
- They can ensure the quality of the snap is reflective of the project's objectives
- They can provide replete documentation for all the various deployment methods for the application
As for dropping the snap entirely, that would come with some push back from the community, as there are currently 66,829 deployments of the snap globally.
I also saw @brlin-tw 's PR (https://github.com/aristocratos/btop/pull/1261) for upgrading to core22, but the snap has been core24 for some time (see here: https://github.com/kz6fittycent/btop/blob/main/snap/snapcraft.yaml).
Found out that
btopon all my machines (Ubuntu 20+) is delivered via APT, and thus outdated: $kenyawest: ~ ❯ sudo apt-cache policy btop btop: Installed: 1.2.3-2 Candidate: 1.2.3-2 Version table: *** 1.2.3-2 500 500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages 100 /var/lib/dpkg/status I thought of using Snap store to get new version, but seeing this issue, I am so confused...
Is there an option that Snap version could possibly become stale, too?
What do I do now? Rely on Snap, choose binary installation, or wait some time for this issue to resolve?
The snap is not likely to become stale, at least while I am maintaining it. See here for the latest version available as a snap:
snap info btop
name: btop
summary: Resource monitor that shows usage and stats
publisher: James Tigert (kz6fittycent)
store-url: https://snapcraft.io/btop
contact: https://github.com/kz6fittycent/btop
license: Apache-2.0
description: |
Resource monitor that shows usage and stats for processor, memory, disks, network and processes.
C++ version and continuation of bashtop and bpytop.
snap-id: UgRB8x3LtPA9L2Qo4G26ozMRImexxYzM
channels:
latest/stable: 1.4.5 2025-10-05 (912) 1MB -
latest/candidate: ↑
latest/beta: ↑
latest/edge: 1.4.5 2025-10-04 (912) 1MB -
As for dropping the snap entirely, that would come with some push back from the community, as there are currently 66,829 deployments of the snap globally.
This was meant as 'drop snap packaging code from this repo'.
@Kenya-West
Is there an option that Snap version could possibly become stale, too?
Not necessarily, as it depends on whether the snap publisher can follow the upstream's releases well.
According to @kz6fittycent 's reputation, I wouldn't be too worried about that.
What do I do now? Rely on Snap, choose binary installation, or wait some time for this issue to resolve?
Use whatever you feel comfortable with. As a general rule of thumb, you should only install software from third-party sources if you trust their publishers. Please do your research before making any decisions.
@kz6fittycent
I also saw @brlin-tw 's PR (#1261) for upgrading to
core22, but the snap has beencore24for some time (see here: https://github.com/kz6fittycent/btop/blob/main/snap/snapcraft.yaml).
Thanks for the heads up! I don't really know it is there.
In that case, I would suggest dropping the snap assets from this repo, as it doesn't provide much value in the current state and may confuse users into thinking that it is the single source of truth.
We should also update the snap listing so that the packaging source can be transparent to the users.
We also might need to update the support contact of the snap, as it may introduce unwanted bug reports here:
$ snap info btop | grep ^contact:
contact: https://github.com/aristocratos/btop/issues
I would also encourage the project maintainers to gain access to the store backstage and the packaging repository so they can be more involved in the operations of the distribution, which seems to be working quite well at the moment (aside from the GPU support part, which I hope we can improve soon).
I also saw @brlin-tw 's PR (#1261) for upgrading to
core22, but the snap has beencore24for some time (see here: https://github.com/kz6fittycent/btop/blob/main/snap/snapcraft.yaml).Thanks for the heads up! I don't really know it is there.
In that case, I would suggest dropping the snap assets from this repo, as it doesn't provide much value in the current state and may confuse users into thinking that it is the single source of truth.
Initially, that was my hope - that the upstream project would be the one-stop shop instead of two repos. I am happy to help in supporting the project with the snap itself, but there have been a couple times where the application itself had an issue that I needed to work with @aristocratos to fix. Whereas this project has multiple contributors, and I am just one person, I think it makes far more sense for everything to be centrally managed and maintained.
We should also update the snap listing so that the packaging source can be transparent to the users.
We also might need to update the support contact of the snap, as it may introduce unwanted bug reports here:
$ snap info btop | grep ^contact: contact: https://github.com/aristocratos/btop/issues
Updated my yaml to reflect my contact info instead of this repo - see my comment above regarding my reservations with doing this.
I would also encourage the project maintainers to gain access to the store backstage and the packaging repository so they can be more involved in the operations of the distribution, which seems to be working quite well at the moment (aside from the GPU support part, which I hope we can improve soon).
100% agree. I am more than happy to contribute to this project by maintaining the snap, but should I ever become unable to maintain it, it would be bad for a lot of users relying on the snap.
@kz6fittycent @deckstose I have no interest in maintaining any form of distribution besides the musl builds that are shipped with the releases. I believe I've been consistent in this any time someone has brought up the question of distributing.
That being said, I don't mind if automation for snap (or whatever else distribution tool) is added to the repo, as long as it's fully automatic.
If it brakes, I would just leave it up to those have an interest/knowledge in how to fix it. And if no one fixes it, it would eventually be removed.
