Ichthyostega
797174ef19
On the Website, there is a set of interconnected pages related to compiling from source, the Debian package and our DEB depot. Although these pages have always been superficially kept up-to-date, the overall presentation feels dated and generally not well organized. During the last weeks, I have almost entirely rewritten all those pages, added information about the (now reworked) DEB package, explained the alternate ways to build from a Debian source package (notably the `mk-build-deps` for handling the build dependencies, which effectively the only method which always worked during the last years, since our DEB package was totally outdated) Furthermore, I have tested most of the build steps with the current source trees, repositories and package definition, and finally I have also updated and polished the front-page of our DEB-Depot (-> see commit on the depot-Branch) Wheew ... quite some work done!
162 lines
8.2 KiB
Text
162 lines
8.2 KiB
Text
Lumiera Debian Depot maintenance
|
|
================================
|
|
:Author: Hermann Voßeler deb@ichthyostega.de
|
|
:Date: 3/2011 · 11/2025
|
|
|
|
//Menu: label Debian Depot
|
|
|
|
|
|
At Lumiera.org, we maintain a link:/debian[Debian DEB depot],
|
|
that can be used as _package source_ for Apt to allow automatic installation
|
|
of our custom packages for Lumiera.
|
|
|
|
This Debian-Depot is part of the Lumiera build infrastructure.
|
|
It is managed (semi) automatically, based on the
|
|
https://salsa.debian.org/brlink/reprepro[reprepro] tool by Bernhard Link +
|
|
-> https://wiki.debian.org/DebianRepository/SetupWithReprepro[Debian Wiki]
|
|
· https://manpages.debian.org/trixie/reprepro/reprepro.1.en.html[man page]
|
|
|
|
|
|
The Lumiera debian package
|
|
--------------------------
|
|
Since our whole infrastructure relies heavily on the Git version management tool, it seems natural
|
|
to organise also the (debian) packaging with the help of Git. Fortunately, there is a nifty tool
|
|
called link:https://honk.sigxcpu.org/piki/projects/git-buildpackage/[git-buildpackage], written
|
|
by Guido Günther exactly for this purpose: It treats the _debianisation_ as a branch in the
|
|
Git repository, forking off the mainline at the release point.
|
|
|
|
For Lumiera, this _debianisation branch_ is called 'deb' and can be found in the Repository
|
|
https://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git://git.lumiera.org/debian/lumiera].
|
|
|
|
.(re)build the debian package
|
|
[NOTE]
|
|
--
|
|
. step into a packaging work directory
|
|
. `git clone git://git.lumiera.org/debian/lumiera -b deb`
|
|
. `cd lumiera`
|
|
. `gbp buildpackage`
|
|
|
|
-> more explanations regarding the
|
|
link:{ldoc}/technical/build/LumieraDebianPackage.html[Lumiera Debian package]
|
|
--
|
|
|
|
|
|
Debian-Depot for installation via Apt
|
|
-------------------------------------
|
|
It is rather easy to build a simplistic DEB package and then install it locally through
|
|
`dpkg -i` -- however, if we want to support automated installation and upgrades using
|
|
the Apt package manager, we need to build up more infrastructure. One of the reasons
|
|
is that for any source package, a multitude of binary packages might be built and
|
|
provided for different architectures; in addition, we also want to support several
|
|
different distributions (Debian, Mint, Ubuntu...)
|
|
For this purpose,the Apt package manager requires a precisely defined folder structure,
|
|
accessible online via 'https:' or 'ftp:'. For maintaining this folder structure, three
|
|
different levels of complexity are conceivable:
|
|
|
|
minimal layout, manual maintainance::
|
|
place everything in a single directory accessible online. Use only one pseudo-distribution
|
|
and call the (single) component \'.\' -- just dump packages into the directory and update
|
|
the packages list
|
|
|
|
multiple distributions and components, pool directory::
|
|
this setup is already a full-featured Debian depot, just there are some limitations
|
|
on the flexibility: there might be only _one_ version of each package per distribution,
|
|
and all different distributions use a shared pool (and thus require different packages
|
|
to be labeled stringently)
|
|
|
|
major distribution or mirror site::
|
|
similar to the above, this is a complete Debian depot, but it is backed by a database
|
|
and allows for much more flexible configuration and is highly automated.
|
|
|
|
|
|
For Lumiera, it seems the middle option is the right choice: while it still keeps the
|
|
infrastructure simple, it allows for multiple _distributions_ (Debian/stable, Ubuntu....)
|
|
and multiple _components_ (experimental, development, release). The `reprepro` tool
|
|
mentioned above does provide this degree of functionality: Basically it requires a fixed
|
|
directory structure with some control files; the front-end is a commandline tool with a
|
|
lot of options and quite some automation- and extension hooks.
|
|
Internally, it uses an embedded lightweight database.
|
|
|
|
Using `reprepro`, existing source, binary or combined packages can be _added_ (imported)
|
|
into the structure with a single command; the files comprising the package are then
|
|
added automatically to the pool directory and all the indices, directories and GPG
|
|
signatures are created and updated automatically. Previous versions of the same
|
|
package are purged, when not referred by any existing package anymore
|
|
|
|
To summarise the work procedure:
|
|
|
|
. somehow build the DEB package
|
|
. import it with `reprepro` into the depot folder structure
|
|
. share this structure over the web
|
|
|
|
|
|
everyday usage
|
|
~~~~~~~~~~~~~~
|
|
|
|
import a package::
|
|
`reprepro -V -C experimental include trixie lumiera_0.pre.04-1_amd64.changes`
|
|
+
|
|
this adds the given binary lumiera package, together with all sources and the original
|
|
tarball to the `trixie' repository, and there into the `experimental' section
|
|
|
|
dump out an entire repository::
|
|
`reprepro -V export trixie`
|
|
+
|
|
this will __re__generate all of the indices, signatures and metadata of the 'squeeze' repository
|
|
|
|
|
|
Configuration
|
|
~~~~~~~~~~~~~
|
|
All the current configuration and the state of the Debian depot index files is tracked
|
|
in the aforementioned ``debian/lumiera'' Git repository, on a separate branch called
|
|
https://git.lumiera.org/?p=debian/lumiera;a=shortlog;h=refs/heads/depot[`depot']
|
|
|
|
TIP: this is a slightly unconventional setup, insofar the `depot' branch carries
|
|
a directory tree that is completely separate from the main Lumiera source tree, which
|
|
is tracked by the deb branch in the same repository... +
|
|
I did choose this layout because of the marginal relevance of this depot management;
|
|
I just did not want to create __yet another not so useful repo...__
|
|
|
|
The details of our configuration and the current state can be seen here...
|
|
|
|
* primary https://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=conf/distributions;hb=refs/heads/depot[configuration]
|
|
* Logfile of imports: https://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=log/trixie.log;hb=refs/heads/depot[for Debian/Trixie]
|
|
* Logfile of imports: https://git.lumiera.org/gitweb?p=debian/lumiera;a=blob;f=log/noble.log;hb=refs/heads/depot[for Ubuntu/Noble]
|
|
|
|
|
|
[NOTE]
|
|
.Details to note in our setup
|
|
=======================================================================================================================
|
|
- each block in the file 'conf/distributions' defines a repository for a ``distribution'' (e.g. Trixie, Forky, Noble).
|
|
Within such a repo, there are sections named 'Components'.
|
|
- The _override_ files mentioned in the configuration allow to overwrite / replace arbitrary fields in the metadata of
|
|
all packages added to that distribution (We do not currently use this feature however).
|
|
- In this setup, we enabled the _tracking_ function: thereby `reprepro` will keep track of the dependencies between
|
|
binary packages, signatures, debianisation patches and original upstream tarballs. Never packages overwirte older
|
|
ones -- _at any time there is at most one version of a package in the repository._ Parts not referred to anymore
|
|
will be discarded automatically. In our configuration, they are moved into the 'morguedir'
|
|
- Please be sure that the *GPG signing key* is maintained properly and kept secure,
|
|
because it protects our users against evil spirited manipulations by powerful entities.
|
|
=======================================================================================================================
|
|
|
|
|
|
current setup 2025
|
|
^^^^^^^^^^^^^^^^^^
|
|
While we plan to automate most of this packaging business eventually, currently our releases
|
|
and the packaing tasks are performed in a semi-manual fashion. This means that we use some base
|
|
level automation (like `git-buildpackage` or `mk-build-deps` or `reprepro`) -- but the manifests
|
|
and changelogs are maintained manually and the steps for building and importing are launched
|
|
one by one at the console. Our _preview releases_ happen only occasionally and each of them
|
|
changes and breaks a lot, so that an effort towards a higher level of automation seems futile.
|
|
|
|
Typically, _Ichthyo_ builds the packages on his local PC in suitable Docker/Podman containers
|
|
and adds/imports them into the `reprepro` -- changes are then propagated to Lumiera.org via rsync,
|
|
and the changed index files are checked into the `depot` branch and pushed into
|
|
https://git.lumiera.org/gitweb?p=debian/lumiera;a=summary[git://git.lumiera.org/debian/lumiera].
|
|
|
|
The rsync to upload is done with
|
|
----
|
|
rsync -rclvz --progress --partial --delete \
|
|
/local/path/to/Lumirep/depot/ ichthyo@www.lumiera.org:/var/local/www_debian
|
|
----
|
|
|