Providing a debian repository for postfixadmin 3.3.11 #613
CLechleitner42
started this conversation in
Show and tell
Replies: 1 comment
-
Thank you for the above - I'll try and merge your changes in (if no one else submits a PR etc). |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm not sure where I should put this, but this place seems better than the extremely quiet developer mailing list ...
Introduction
A week ago we upgraded our company mail server from Debian 10 Buster to Debian 11 Bullseye (the current
stable
), and found out thatpostfixadmin
is not avaiable asstable
package currently.While
postfixadmin
is still (or back?) in Debiantesting
andunstable
, 1. I found out about that too late and 2. it's too early to switch production servers to Debian 12. So I decided to repeat what I did with 3.1 in 2018 ...TL:DR
Anyone who trusts us ;-) and wants
postfixadmin
current stable3.3.11
for a Debian 11 Bullseye system can get it from our Open Source repository https://deb.clazzes.org/ doing something like the following (asroot
or withsudo
):Public Github to non-public Gitlab to adapations to public deb and git repos
Why different?
I know the common way of doing tiny adaptions or extensions to a Github project is to fork the repo within Github and work here, eventually putting in a pull request or another at some point. But we have to keep a tight ship (ISO27001 calling) and it's always more efficient to keep to our approach albeit it's quirks, so I went a bit different.
Half a year ago we started to use an internal Gitlab instance as the new core of our software production infrastructure and we are moving everything there, from legacy subversion repositories, from github forks, from whereever.
Github to Gitlab
The first step was to create a Gitlab project that basically mirrors the public upstream git repository, https://github.com/postfixadmin/postfixadmin.git. The mirroring happens regularily automatically, that's a Gitlab feature. If we should hit pull restrictions we can switch from public
https
to a dedicated token andssh
.Sub branch
In that Gitlab project I created a new branch
postfixadmin_3.3_clazzesorg
that's based on thepostfixadmin_3.3
stable branch.This also protects our adaptions from being overruled by pulls from upstream.
Adaptions
Converting upstream-patching package to "normal" package
Our infrastructure is made for our software and doesn't fit well with Debian's usual approach to packaging 3rd party software.
So I manually applied debian's patch
debian/patches/config-debian.diff
and removeddebian/patches
as well asdebian/source
.Fixing debian/postfixadmin.examples
debian/postfixadmin.examples
still refers toANNOTATIONS/README.txt
which is nowANNOTATIONS/README.md
.Easy fix, but required.
Changelog and meta data
To reflect the real version I added an entry to
debian/changelog
, raising the debian version to3.3.11-0clazzes0
.To avoid anyone bothering innocent good-shepard contributors about my crimes I declared myself the maintainer and prefixed some regarding fields in
debian/control
withX-Upstream-
.I also had to add some
X-*
fields for our toolchain, the "package builder and archiver" (PBA for short).Other adaptions
.gitignore
needed some more lines to avoidgit commit -a
accidents.Release to public debian repo, via Gitlab CI/CD
Every software we install on Debian servers has to come from debian repositories.
Debian packages we create for Open Source components, our own or not, obviously go to a public repository, https://deb.clazzes.org/.
For almost everything we maintain in Gitlab this happens automatically on git pushes (or merges) via Gitlab's CI/CD capabilites.
Remark: We have a convention-based strategy for
beta
andstaging
versions and repositories, but that's not required here.Mirroring to public git repo
While I feel silly calling my efforts a fork it still would be unethical (and hopefully illegal) to not put the changed sources back into the open.
Therefore our Gitlab-based git repository is mirrored further on to https://git.clazzes.org/ resp.
git://git.clazzes.org/xpkg/postfixadmin.git
, now including ourpostfixadmin_3.3_clazzesorg
branch with all our quirks and all my typos.Future upgrades
The beauty of these structures is how easy it will be (well, should be) to merge upstream upgrades:
Gitlab automatically mirrors (pulls) changes to the upstream
postfixadmin_3.3
branch.All I have to do for a new debian release is to pull to my working copy, to merge (or cherrypick) the changes into the
postfixadmin_3.3_clazzesorg
branch, add adebian/changelog
entry, and push that back to our Gitlab.The rest happens automatically.
That's leaps and bounds easier than anything I could accomplish with a fork on Github.
Beta Was this translation helpful? Give feedback.
All reactions