Bug#949006: debian-policy: Stop recommending stamp files in debian/rules
Hi!
Niels Thykier wrote:
> I would like to propose that we drop or replace the following
> recommendation in Policy:
>
> """
> When a package has a configuration and build routine which takes a
> long time, or when the makefiles are poorly designed, or when build
> needs to run clean first, it is a good idea to touch build when the
> build process is complete. This will ensure that if debian/rules build
> is run again it will not rebuild the whole program. [11]
> """
>
> (And related footnote about using "build-stamp" instead of "build").
[...]
> As I understand it, the primary purpose behind this recommendation
> comes from the need for running "debian/rules build && fakeroot
> debian/rules binary" and thereby repeating the build step in some
> cases (as listed in the text).
I don't have a strong opinion about what we should recommend to do
with poorly-designed makefiles (e.g. wouldn't it make sense for us to
work with upstream to make them less poorly designed?), but I think
this bug report is not characterizing the motivation correctly.
The motivation is the same as the motivation for rules to be
idempotent in any Makefile: it allows one to safely run steps in any
order, rerun them without unnecessary work, and so on.
In other words, this is a quality of implementation issue that affects
all developers working with the source package, not just buildds. If
we switch to a policy that focuses only on buildds working, that would
take away a large part of what I find appealing about working within
Debian.
> However, with the advent of Rules-Requires-Root many packages can now
> be built with a direct "debian/rules binary" call and here the stamp
> file is no longer useful for the above purpose.
>
> Furthermore, debhelper need some complexity in implementing/emulating
> this behaviour. This may sound "easy" until you try to implement this
> "correctly" for the following sequence of debian/rules calls:
>
> debian/rules build-arch
> debian/rules binary-indep
>
> This has resulted in debhelper using arcane trickery such as log files
> (up to compat 9) and its own "stamp-log" (compat 10+). Both
> techniques have their limitations and causes frustrations for people
> that has a "well-behaving" upstream build system as they have to work
> around debhelper's trickery.
>
> Notely, this trickery prevents you from hacking on the upstream parts
> and use "dpkg-buildpackage -b -nc -uc -us" to reduce the build times
> for subsequent builds. You would have to add some rm -f calls to
> delete "internal debhelper state files" as well between each
> dpkg-buildpackage call.
The ideal is to have dependencies correctly set so that if something
changes, the build system knows exactly what needs to be rebuilt. Is
that achieveable in the debhelper context?
Summary: I don't have a strong opinion about what policy should say to
do with poorly-designed makefiles, but let's make sure debhelper
doesn't enter that category.
Thanks,
Jonathan
Reply to: