rebuild debian docker stuff

[simonLeary42]

I was tasked with building a .deb package for Lmod, and was super excited to see @surak's docker workflow. It seems to me like it needs some love before it can be expected to run by any arbitrary user.

The current debian docker script:

• is hard coded to a fork
• is hard coded to a name and email
• must be run in another fork with a debian branch and an upstream remote
• must be run on a BSD system
• must be run in a specific directory
• pulls from upstream, pushes to fork, then creates docker container, then pulls from fork inside container
• outputs only a .deb file
• continues executing commands after previous commands have failed

and all package dependencies are hard coded into the dockerfile.

The new scripts:

• instruct the user how to add an upstream remote if no such remote already exists
• are not hard coded to a specific person's name / email
• can be run on linux and BSD systems (tested on mac with and without linuxify)
• can be run from any path
• copies cwd into docker container, no pushing/pulling required
• outputs all files created by debuild in a tempdir
• stop after the first failed command

and the dockerfile automatically installs whatever dependencies are present in the control file, no hard coding.

I also did a little refactor:

docker/build.sh
docker/Dockerfile

has changed to:

debian/update-version.sh
debian/debuild.sh

build.sh has been split into update-version.sh and debuild.sh, and Dockerfile has been moved into a heredoc in debuild.sh. I think the paths are more intuitive this way.

I had no idea what to put for the name / email on the deb changelog if not a specific person. I'm not sure if that name / email must match the GPG signing key. I went with Lmod automatic deb changelog script <[email protected]>, but I'd be happy to change it if there's something else that makes more sense.

I'm not entirely sure how much use there is on your end for this kind of workflow. I'm not sure if it makes sense to make this into a github action since it only needs to run at each release, not each push to master. If making a release takes manual action already, then maybe it's reasonable to expect someone to run update-version.sh and commit?

And then there's the .deb file. I'm not sure if you want to publish a binary package, or if you'd prefer to just give people the means to make their own. If you do intend to publish a .deb, I assume it's better to go through the official deb channels and let people add Lmod to their apt sources. And if build.sh/debuild.sh is just a tool for people to make their own packages, maybe it belongs in contrib/?

[surak]

Hey Simon!

Glad to hear that the Debian package generator got some love.

I made it for myself, to run on my machine, and in this way, it just works. I keep generating Deb files for each release on my fork of lmod and advertising them on my channels.

It’s not a bad practice to add the deb files on each release IMHO. In fact I prefer when I got to a repo and there’s a binary of that software.

That said, the right way would be to make it into Debian itself and let the other distros pick it up from there.

I have author rights on salsa.debian.org for lmod, although I haven’t touched it in ages. The other maintainer modified things heavily and was very worried about having a clean git history, so I kinda let them do whatever they want and kept distributing lmod on my github.

Do you want to overtake the Debian official release? I think it’s always good when a software is distributed by the authors themselves. If not, I can try and update things to a more recent state. Just tell me.

[surak]

LGTM

[simonLeary42]

@surak I would be happy to contribute to the debian release. I am still learning my way around the ecosystem, so I would at least need someone to review my merge requests. Is the other maintainer still active?

[surak]

The last commit by him was 2 years ago. I can take over, I don’t think I need to care about them after all this time. And if you want, we can do it together.

[simonLeary42]

Sure, together sounds good. So you plan to overwrite the git history? I had been trying to wrap my head around all the details in the official package, but I'm happy to start fresh on monday with yours.

[surak]

I seriously don’t care AT ALL about the git history of old versions of the Debian package to be honest.

What’s the point, actually? It doesn’t reflect the history of development of the software.

We can start fresh soon.

[surak]

Meanwhile, I'm still publishing them on my fork: https://github.com/surak/Lmod/releases/tag/8.7.44

[surak]

https://github.com/surak/Lmod/releases/tag/8.7.45