3 ms·
I'm a DD, and I can see his point of view. The debian build system started form the simplest thing that would work, and grew from organically from there. Buil
by rstuart4133 6y ago
I'm a DD, and I can see his point of view. The debian build system started form the simplest thing that would work, and grew from organically from there. Building in the same area as the source for example, and then having to clean the mess up as opposed to just building in a clean temporary directory like rpm did from day 1. We only got clean separation of debian patches from the upstream sources a while ago. Kinda. Sometimes debian has to repackage the upstream sourced due top copyright problems. uscan is hardly a nice solution syntax wise, nor is is policy so there doesn't have to be a fully scripted way of going from upstream source to debian package. And there is the dh sequencer, which splits the configuration into a zillion tiny little files. It goes on.
Like any organic solution it works, and somewhat impressively works for all the use cases created by debian's 60k odd packages. However, pretty or simple it isn't. Learning the interactions of the various dh_ helpers with the build systems they try to automate, the "guesses" (term they use in the manual) they make and when they are applicable is a huge job. The learning hill is consequently steep, and I would say unpleasant.
However, I don't want to undersell the end result. The QA checks done FTP masters, lintian, the discipline imposed by testing and the long transition from testing to stable mean the end result is very, very good. Better than I've seen in any other distro, including the .rpm ones I used to use. From a sysadmin point of view, that trumps everything. From what I can tell debian could be described as a bunch of programmers beavering away for free to produce something that none of them could produce on their own - a Linux distribution so good the base their day jobs on it.