On 10.04.19 03:53, Russ Allbery wrote:
Hi,
> Possibly my least favorite> thing about RPMs is the spec files, because by
> smashing everything>
together into the same file, the syntax of that file is absurd. This
bit> is a shell script! This bit is a configuration file! This bit is>
human-readable text! This bit is a patch list! This bit is a file>
manifest! This bit is a structured changelog! This bit is a bunch of>
preprocessor definitions! Aie.
Same for me.
Certainly, deb and debian methods also have their downsides:
#1: text-based patches inside debian/ make everything unncessarily
complex, as soon as you're working w/ a decent VCS (eg. git).
their historical purpose is long obsoleted (since over a decade)
#2: for many common usecases, full-blown makefile is too much
complexity, and even w/ debhelper, knowing which variables have
to be set in which exact way, isn't entirely trivial.
some purely declarative rule file (eg. yaml) would make those very
common usecases much easier.
#3: when you have to generate the control file on the fly, things easily
get messy - i'm currently fighting here w/ packaging the kernel.
the problem is that this file contains the source package name and
source dependencies, which need to be known before the control file
can be generated. circular dependency.
I'm currently working around that by having a separate control file
(debian/control.bootstrap) which is used by my build machinery
(dck-buildpackage) in a separate preparation step, when control file
is missing.
But still, IMHO, the debian packaging toolstack is much superior to
anything else i've every encountered.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
