Skip to content
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

keybinder packaging #15

Open
bdubbs opened this issue Mar 1, 2019 · 6 comments
Open

keybinder packaging #15

bdubbs opened this issue Mar 1, 2019 · 6 comments

Comments

@bdubbs
Copy link

bdubbs commented Mar 1, 2019

I know this is very late and the last release was a year ago, but when I download the tarball for the latest release from github, I get:
keybinder-keybinder-3.0-v0.3.2.tar.gz
when I think is should be simply:
keybinder-0.3.2.tar.gz

The tarball also extracts to the directory keybinder-keybinder-3.0-v0.3.2 and this is confusing.

@ulidtko
Copy link

ulidtko commented Mar 2, 2019

Well, there are two tarballs there: the one you describe is labeled by GitHub as "Source code (tar.gz)". Right above that, there's also keybinder-3.0-0.3.2.tar.gz which is source tarball, too. That one contains keybinder-3.0-0.3.2/ just as expected. On the -3.0 part, note the README paragraph:

The package keybinder compiles against GTK+ 2 while the package keybinder-3.0 compiles against GTK+ 3. The two packages can be installed in parallel.

All in all, I agree with you that the "Releases" page is more confusing than it needs to be. Obviously, some cleanup needs to be done. Would you care enough to prepare a patch? :)

@bdubbs
Copy link
Author

bdubbs commented Mar 2, 2019

I do not know how to do packaging on github.

I would name the gtk3 package keybinder3-0.3.2.tar.gz or perhaps keybinder-1.0.0.tar.gz. The change to gtk3 seems to be significant enough to warrant a major version number increment.

Are you going to support both versions? If so, then the 1st option seems appropriate.

By the way, since BLFS supports over 1000 packages, it is welcome if download via wget is supported as well as via browser. What we use now is:

https://github.com/kupferlauncher/keybinder/releases/download/v0.3.1/keybinder-0.3.1.tar.gz

@ulidtko
Copy link

ulidtko commented Mar 4, 2019

That URL is totally fine even for a book. GitHub doesn't try to make downloads difficult, wget or whatnot.

Next, the "support both versions" question is not really for me to answer... @kupferlauncher can you please promote me to a contributor or better? I've been maintaining Guake for some years, and using/watching libkeybinder closely. This repo needs maintenance, and someone's gotta do it. I can do it.

If I were to answer indeed: I'd ditch the gtk2 support from master (meaning: just archive it in a gtk2 branch) and release version 1.0.0. Just like Guake did years ago -- no complaints received ever since.

Finally @bdubbs, since you mention BLFS, I believe this indicates you're well versed in GNU Autoconf/Automake?.. "GitHub packaging" is really really simple: it just takes a zip archive of everything in master, and posts that as "Source code (zip)", plus any additional artifacts that the releaser uploads manually. OTOH, I know that autoconf generates separate targets to explicitly build a distribution/release tarball. Would it be possible to simplify this process? Ideally, just a plain tar.gz of all VCS-tracked sources (at a tagged revision) should be good enough as a release tarball.

@bdubbs
Copy link
Author

bdubbs commented Mar 4, 2019

@ulidtko, I do know how to use wget from github, although it is not always obvious. The packaging of keybinder-0.3.1.tar.gz is fine. The packaging of keybinder-keybinder-3.0-v0.3.2.tar.gz is cumbersome.

I'll note that many packages on github specifically place a version specific url on their release page. For example https://github.com/apple/cups/releases/

@rubyFeedback
Copy link

I was about to file a separate issue but just discovered this here. I agree with bdubbs.

This is not necessarily unique to linux from scratch but I noticed my ruby scripts having
a few problems with the new name:

keybinder-3.0-v0.3.2

If you look at slackware:

http://www.slackware.com/changelog/current.php?cpu=x86_64

to jump to:

l/keybinder-0.3.1-x86_64-2.txz: Removed.
l/keybinder3-3.0_0.3.2-x86_64-1.txz: Added.

So Patrick named this "keybinder3-3.0" which adds to the confusion,
because the sourceball does not have that at all. :-)

So I think I am not the only one confused; neither Patrick, nor bdubbs.

From the thread I read that the 3.0 indicates support for gtk+3.

Now first - I think it is bad to indicate support for gtk+3 like this
in the name. But ok.

HOWEVER had, what I find REALLY bad is then the ".0" part
because that just makes no sense? Why the .0 there?

Keep in mind that gtk+ is at this URL right now:

http://ftp.gnome.org/pub/gnome/sources/gtk+/3.24/gtk+-3.24.20.tar.xz

If you look, the name is "gtk+" and the version is "3.24.20". This is
a very simple scheme to understand. I don't know what the ".0"
part does here for keybinder.

Perhaps renaming the project would be cumbersome too, so I may
understand that this is not done - but I think you have a semi-unique
naming convention here, and there may be more confusion along
the way.

Personally I think the naming schemes such as for gtk+ are very
simple - it is much better to have a leading name part, and
then simply a version. The 3.0 part is confusing.

The package keybinder compiles against GTK+ 2 while the package keybinder-3.0
compiles against GTK+ 3. The two packages can be installed in parallel.

This is a weird comment because a) most .so files are versioned anyway,
b) programs such as python2 and python3 don't have a naming scheme
like described here but work fine (and c), on distributions such as GoboLinux
it would not matter anyway since you can have any different version
combined and combinable - that's the whole point. I understand that
for pure FHS based distributions this is harder, but see the python
situation).

That URL is totally fine even for a book. GitHub doesn't try to make downloads
difficult, wget or whatnot.

Not really. Github has not learned yet that simplicity is key:

so an archive called:
v1.0.0.tar.gz

should expand to PRECISELY that name as is, all the time. Instead
github does some fancy repackacing. It's possible to avoid it by using
other URLs, or just automatically repackage locally anyway, which I
do via scripts too. But still - it's annoying.

Guys, if you don't want to believe me (my fake-package manager
currently tracks 3663 programs, and keybinder is currently added
so the count is +1 - in fact that is why I actually came to this
issue tracker), believe bdubbs because maintaining LFS is a
tough job - and he has had to deal with lots of
packages too.

Simplicity is great! Let's not bloat up the names to infinity here.

@ulidtko
Copy link

ulidtko commented May 28, 2020

Not sure if this helps, but there's a common trick to correct whatever naming blunders:

https://github.com/kupferlauncher/keybinder/archive/keybinder-3.0-v0.3.2.tar.gz#named-as/whatever-you-desire.tar.gz

Keep in mind that this repo hasn't seen its maintainer in ~ 3 years. @kupferlauncher ping!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants