Closed nivex closed 2 years ago
1: no real opinion on.
2: How would this benefit or help the project or end users when using the GitHub release management system?
I don't think it's needed when the api can provide all release specific versioning info needed if that info is required,
Whereas using a system like this https://ftp.gnu.org/gnu/libtool/ it would make sense.
Over the years I've gotten in the habit of running tar tf foo.tar
to check for tarbombs, but not everyone does. Also, sometimes I forget. In the case of this project I would end up with a directory full of random files. This is not a fun experience, especially if one does this in their home directory.
As an end user, I go to this project's release page and grab a tarball. I don't know anything or care about GitHub's release management system. It would be a convenience to be able to see at a glance of the filename on my local filesystem what version(s) I have downloaded (especially if they've been sitting there awhile) rather than have to unpack it and poke around.
Not sure how or why this changed, but the most recent release (1.2.13, at the time of writing) now contains a folder within the tarballs.
I noticed this because it broke my package manager and I was looking for an open or closed issue related to this to understand the reason for the change, but the only thing I found was this issue here, which leads me to believe it was not really intentional? 🤔 I didn't have the time to dig deeper but if someone finds something, I'd be interested in the details. Other than that, I hope it remains stable now.
@Gerrit-K See https://github.com/aristocratos/btop/issues/242
Which package manager are you using that uses the release binaries from github?
@aristocratos sorry, "package manager" was probably not the right term here. It's merely a zsh plugin manager (zinit), which can also be used to download arbitrary artifacts from github release pages. It automatically extracts tarball archives, but in most cases I need to point it to the correct binary path. This path has changed in the recent release, which is how I caught it. But the fix on my end was pretty simple. Thanks for providing the context :+1:
1) The current .tar files are tarbombs. It would be best to have all the files in a directory inside the tarball. 2) It would be nice if the filenames (and the future directory mentioned above) contained the version of the release, eg:
btop-1.2.7
instead of justbtop
.