These are notes for an experimental build system; feel free to ignore it or participate with constructive critism. # Declarative package rules This is a draft/PoC on replacing the use of "%:\n\tdh $@" in d/rules. The current implementation sadly has a number of leaky abstractions and performance issues that are fundamentally unsolvable (in a non-hacky way) with the current interface. ## Scope - degrees of freedom and limitations of scope * The draft will assume that we are allowed to use something else than a Makefile for debian/rules. * The draft assumes that the builder is dpkg-buildpackage and the package have R³!=binary-targets (IOW, we only have to deal with "clean", "binary", "binary-arch" and "binary-indep" as entry points). * It assumes that we can handle static ownership declaratively (a la mtree) * We ignore the "bootstrap issue" for the tool. I.e. for now we do not care about minimal (build-)dependencies for this tool. ## Design constraints ### Things that worked really well in debhelper: * Anyone could create their own add-ons and build systems decentralized * There were no requirements on implementation language for the tools (the glue had to be perl though). * Non-standard behaviour (override targets) were easy to define and came with a high degree of flexibility. * Individual tooling were generally simple and well-defined * The debhelper sequence (and tools with --verbose) are generally very transparent IRT what actions they take. ### Things that worked less than ideal: * The interaction between dh and the makefile was fragile and leaky. (see #880840) * Performance is less than ideal for small packages. The startup time of individual tools were low, but we are stuck with running at least 20 helpers (compat 10) and in many cases more. * Sharing data between helpers also requires ad-hoc files in random places. * Overrides were generally on the "macro"-level of things. If you needed "micro"-level things, you generally had to DIY. This is partly an artefact of the "API" of each tool being cli arguments or very simple files. * It was difficult to "do the right thing(tm)" automatically in cases where you had to know how packages related to each other. * By design, debhelper attempted to avoid built-in logic for many things, preferring to delegate it to a different tool. In many cases this worked fine because the problem were only applicable to a well-defined subset of packages. But introducing a binary for the sole purpose of aiding debhelper with a global Debian-specific package thing is a tough sell. (Multi-Arch field, etc.) ### Build systems The tool should should be able to auto-detect the build system and pass all the default options to it. It must understand that somethings builds need to be done more than once (with different parameters) and it must provide an easy way for the maintainer to set these different parameters per build. As a large subset of parameters are often common, the tool should provide a way to reuse parts of the parameters. Commonly, the build consists of multiple steps (e.g. configure, make and make install), the tool should be able to chain these without manual configuration from the maintainer. Again, when one of the steps requires manual overrides from the default, the maintainer should only have to override that particular step. The build parameters eventually need more complexity than can ever reasonably be put into a declarative interface, so this will need a way to call a script in the package to compute the desired parameters (see gcc-X and libreoffice for examples here). ### Overrides * As a maintainer, I want to overrule a specific action/setting for a particular file in a particular package. This ranges from things like permissions, ownership, FS attributs to how the file is stripped (if stripped at all) etc. * I will eventually want apply the same non-default the action/setting to multiple files (possibly even across multiple packages). This must be done in a "DRY" matter. * When multiple "conflicting" overrides apply to the same file, there must be a well-defined "resolution" for each setting. This might not be the same for all settings. - Example: All files in dirX must be mode 0444, except if they are scripts or ELF binaries, in which case they must be 0555. - Example: All ELF binaries must be stripped using with --strip-unneeded except $LIST_OF_FILES, which must not be stripped at all. ### Debian Policy vs derivatives vs other use cases The debhelper tools have been a very strong asset for Debian maintainers and derivatives that closely resemble the requirements of Debian Policy. However, it falls short for derivatives further from the Debian Policy or alternative use-cases (like flatpak). ### Transparency The tool should provide at least the level of transparancy that we had under debhelper. Ideally, it would have various degree of verbosity to provide additional information (the "quiet", "non-quiet" and "verbose" levels in debhelper have on occasion been missing additional levels of verbosity) ### Compatability Like with debhelper, this tool will never be perfect from the get go. We will eventually need to change behaviour and we need some way for people to "opt-in" to it when they are ready. Ideally, the tool would be able to show the maintainers what changes they need to beware of per package. Like a "diff" of what happened under the "old" compat level and what happens under the new compat level. It would be great if we could make it easier to support multiple compat levels to cater for maintainers that wish to have a single source that can build for multiple distros and suites (e.g. unstable to oldoldstable) at the same time.