Bits from /me: Forgetting the Simplified Representation for Debian Packaging?
Hi everyone,
This is not a new idea. I realized that the "DUPR" project
is dying. I removed all the junk from the project and extracted
very core part (redesigned after the last duprkit discussion)
of it. Here I'll present the very core part of it to you, and
let's decide whether or not to sentence the project to die.
Please give me a boolean answer.
My every move in my Debian work is more or less related
to scientific computing, where SIMD/performance matters,
although this area has always been dominated by non-free
software. At the beginning I thought "maybe we can do
something to help users obtain SIMD-enabled binary packages".
All of my attempt so far toward this direction failed:
SIMDebian, DUPR. Sorry for a series of failures, including
the deep learning one. I'm already used to failures. So
if something destine to fail, why shouldn't it fail
early?
If you don't care about the remaining very core idea of
duprkit, then this is the end of this email.
Thanks for your attention :-)
=== remaining core idea for durpkit ===
The very core idea is a simplified representation for debian
packaging, I call it "recipe". The main functionality of helper
program is to translate the information in recipe to a debian
directory. Original design was shell-based, that's ugly and
introduced learning cost since many of your familiar keywords
have been re-mapped.
In the simplest case, the Recipe is just a YAML file with
extremely similar look compared to d/control:
https://github.com/dupr/duprkit/blob/master/examples/tq.rcp
Every key in d/control has been retained. Some extra keys
such as Debhelper-Bulidsystem are added for hinting d/rules
generation. Apart from that, the keys matching
regex("override_.*") are special: their content will be dumped
to d/rules during d/rules generation. In the above tq.rcp
case the dh_auto_test will be noop'ed.
However that's not all of the idea. Take a look at here:
https://github.com/dupr/duprkit/blob/master/examples/apt-nosync.rcp#L8-L16
In the YAML file, for every binary package, it's
Uppercase-char-leading attributes will be dumped to d/control,
while lowercase-char-leading attributes will be dumped to
d/<binary-package>.<attrib-name> file.
You can also browse other examples in this directory:
https://github.com/dupr/duprkit/tree/master/examples
This debian packaging representation cannot be further
shrinked. With the help of HFT, some small text files
could be conveniently embedded into the recipe.
As a side effect, I found this "recipe" very suitable
for "packaging tricks so these tricks can be managed
by dpkg", such as:
https://github.com/dupr/duprkit/blob/master/examples/py3-as-usr-bin-python.rcp
https://github.com/dupr/duprkit/blob/master/examples/fdfind-as-usr-bin-fd.rcp
https://github.com/dupr/duprkit/blob/master/examples/apt-nosync.rcp
A simple vim highlighting script for "recipe" can be found
in the repo.
Upon this "recipe" file, we can implement more things such as:
1. debian user repository. recipe-based, doesn't release
source, no burden to review license.
2. manually hinted debian directory generation. debian
contributores could manually write such recipe and
convert it directly to a debian/ directory into a
specified desination directory. To some extent I like
to generating debian/ directory like so. dh_make and
debmake are bounded by their weird usage, that's why
I memorized the debian packaging template and do
manual debianization without any helper.
3. automatic debianization. writing helpers to generate
the simplified representation "recipe" is much easier
than directly generating debian/ directory itself.
...
If you have ever wrote any .PKGBUILD (Archlinux build system)
file or .ebuild (Gentoo porage) file, it will be easier to
understand the design of "Recipe", since we don't have a
single-file format for directly generating .deb packages
(through multiple well-separated steps).
Ok, I'm at no mood to say more about it.
Afterall the examples are enough to present it.
So be it.
Reply to: