[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RFC: New dpkg-build-api levels



Hi!

Some time ago I started work on a new dpkg build API level system
resembling the one used by debhelper. My current WIP is at
<https://git.hadrons.org/git/debian/dpkg/dpkg.git/log/?h=pu/perl-Dpkg-BuildAPI>,
which I'd like to finalize and merge for 1.22.x.

This works by making packages build-depend on «dpkg-build-api (= N)»
(which dpkg-dev then provides), or by setting the environment variable
DPKG_BUILD_API=N (which overrides the value in the file, but might emit
a warning if it's different). This will control what the dpkg build API
is for that package. There is also a make fragment file (buildapi.mk),
and a companion tool to extract the build API level called dpkg-buildapi(1)
to be used from scripts or similar.

The main reason behind the environment variable is to avoid having to
re-parse the control file all over the place, or possibly for testing
purposes (local or global). Unfortunately I don't see a way (that does
not involve layer violations) to delegate driving the level to a helper
like debhelper (which could then automatically set specific dpkg-build-api
levels from its own levels) because this needs to be set before something
like debhelper is even in the picture, but it could still tie them by
making them a requirement and otherwise failing, so it could get some
baseline guarantees.

This should make it possible to change current defaults that we could not
otherwise change. The idea would be that level 0 would keep the current
semantics, where behavior might be changed after specific global
transitions, or the usual deprecation cycles or similar, but for N >= 1,
the behavior will be set in stone once defined and can only be changed
by adding a new level.

The current list of behavior change candidates for N=1 includes:

 * dpkg-shlibdeps no longer uses the LD_LIBRARY_PATH environment variable.
 * dpkg-buildpackage defaults to Rules-Requires-Root to no.
 * dpkg-buildpackage requires all required debian/rules targets.
 * vendor.mk defaults to using dpkg_vendor_derives_from_v1 for the
   dpkg_vendor_derives_from macro.
 * default.mk defaults to including buildtools.mk.
 * dpkg-buildflags changes default build flags (TBD).

And that last one I'm still working my way through, but I'll send a
separate mail for that one.

So I'm interested in feedback on whether people see any issue with the
above, and in particular Niels input (although I've already floated
this to him in the past) on whether this plays nicely with debhelper,
or whether there is something specific that could be improved or
changed or similar for its usage, or further proposals for behavior
changes.

Thanks,
Guillem


Reply to: