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

Publish tags for submodules corresponding to Hercules releases #530

Open
matoro opened this issue Dec 1, 2022 · 4 comments
Open

Publish tags for submodules corresponding to Hercules releases #530

matoro opened this issue Dec 1, 2022 · 4 comments
Labels
Enhancement This issue does not describe a problem but rather describes a suggested change or improvement.

Comments

@matoro
Copy link

matoro commented Dec 1, 2022

Hi, I have been packaging the last two releases of this version of Hercules for Gentoo in my overlay (basically a personal repo). I have been using it to test Gentoo s390 guests and it works great (on a PowerPC host, no less).

The official Gentoo repository packages only the original Hercules version which is running into maintenance troubles now: see https://bugs.gentoo.org/show_bug.cgi?id=521032, https://bugs.gentoo.org/show_bug.cgi?id=879629. I would like to get my version of this version into the official repository but right now the main blocker are the way the split-out submodules (crypto, etc) are included. I do have a method for building them from source, but the problem is that there is no indication of what commit of each module corresponds to a given Hercules release. In my overlay, I use 9999 ebuilds, a.k.a. live packages, that just git clone the latest code. This is not allowed in the official repositories for reproducibility purposes.

I see that you make a commit like 8b5342d before a release. Basically, all that I need is some indication of what the corresponding commit in the submodule libraries those binaries are built from. Extra awesome if you could also create git tags in the submodule repositories (for cleaner URLs) but not strictly necessary. Hope this isn't too much of a burden, thank you for the amazing work.

@Rhialto
Copy link
Contributor

Rhialto commented Dec 10, 2022

With my hat on as packager for pkgsrc, I second this motion. Having clear releases is much better than having to guess which commit to package. If you create tags in the repositories, like for the main hercules repostory, github will make tar files available, and that is much nicer for packaging than having to deal with git.

@wrljet
Copy link
Member

wrljet commented Dec 10, 2022

Agreed

@matoro
Copy link
Author

matoro commented Dec 10, 2022

With my hat on as packager for pkgsrc, I second this motion. Having clear releases is much better than having to guess which commit to package. If you create tags in the repositories, like for the main hercules repostory, github will make tar files available, and that is much nicer for packaging than having to deal with git.

You can already generate tar files from arbitrary commits without needing a git checkout, e.g. https://github.com/SDL-Hercules-390/telnet/archive/commit/729f0b688c1426018112c1e509f207fb5f266efa.tar.gz

It's just better to have a tag to attach it to so we don't have to guess which submodule commit goes with which release tag.

@Rhialto
Copy link
Contributor

Rhialto commented Dec 10, 2022

You can already generate tar files from arbitrary commits without needing a git checkout,

Ah I guess then that's how it's handled already, I didn't really look into it recently.

@Fish-Git Fish-Git added the Enhancement This issue does not describe a problem but rather describes a suggested change or improvement. label Dec 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement This issue does not describe a problem but rather describes a suggested change or improvement.
Projects
None yet
Development

No branches or pull requests

4 participants