Re: Increasing regularity of build systems
Michael Alan Dorman writes:
> "David N. Welton" <davidw@linuxcare.com> writes:
> > Hi, while working on the ARM port, I've begun to become frustrated
> > with the IMO, not entirely necessary diversity in our "rules" files.
>
> I agree with this. And I think debhelper is of enourmous value. I
> have been sceptical of other scripting systems (having written one
> myself at one point, I think I had better reason than most), but I
> think debhelper tends to be sensible and useful.
well, there are always some things, that debhelper does not support
(have a look at the gcc rules files, or gstep-core in Incoming for a
more simpler variant):
- adjusting an installation: moving files from one location to another
to fit the FHS or to suite the maintainer's style and habit ...
- extracting information from various upstream source files and use
them in debhelper files. That's one of the reason I do not like
.dirs and .files files and I put all these in the rules file. How do
I specify an architecture-dependent file in a foo.dirs file? How
do I specify a shell variable in a postinst file, which is dependent
on the upstream source?
Another thing is the base name of packages, which change often for
libraries and has to be hardcoded as the filename of debhelper files.
> If it makes you feel better, it was worse for the alpha (and probably
> even worse for m68k, I'm sure, since they had at least dealt with some
> people's bad habits before the alpha was started).
well, these are omissions, which should be fixed in most packages by now.
[stuff about configure target deleted]
> subsequent introduction into makefiles and the like) wouldn't break
> the compile on your machine, but then when the package gets updated
> upstream, we have to reapply all the patches, etc.
That's a very important point! Currently you do have ABSOLUTELY NO
possibility to see the single patches which are applied to the Debian
version (only the changelog, but that's not enough to know, that bug
#x is closed by applying patch foo, which you cannot find anymore; but
the verbosity of changelog entries is another issue). We are missing a
possibility to identify a set of changes to a specific file. And it
get's worse, if the clean target doesn't really clean the upstream
source, which is often the case, when builddir != sourcedir.
You find an intermediate solution with some patch rules (applied in
the gcc, glibc, gstep-core packages). Patches are put in a
debian/patches directory and are applied before configuring and
building the package and are unapplied in the clean target. That makes
patching the upstream source the first time a bit more work, but you
clean patches, which you can send upstream and it's easier to move
them to the next major version.
A more complete solution should revamp the debian source package
format to incorporate
- multiple upstream sources forming a Debian source
- patches or patch sets which are applied to a Debian source
- separation of source directory and build directory
I don't know anything about the dpkgv2 format, but a consideration of
such features in a new format would be worthwile.
Reply to: