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/?