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.