Re: RFC: New dpkg-build-api levels
Guillem Jover:
Hi!
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 [...description omitted...].
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.
I think this is fine as a starting point. If you had found a solution
for the delegation, I think we should have seen it with
Rules-Requires-Root.
If we want to solve the delegation issue, we have to change the layers
in our build system and that is a topic for another day.
For the ENV, seems fine. Might also be useful for debhelper to know what
it can expect from dpkg further down the line.
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).
Seems reasonable.
I have a few minor suggestions for the upgrade documentation.
I would concrete recommend that you swap the order of the upgrade
levels, so the latest is in the top.
By having the latest compat level in the top, the readers will only
scroll over compat levels that are relevant to them. Right now, it makes
no difference, but when you have 10+ compat levels (which debhelper
accumulated) this will change.
At such a time, most people will only be 1-2 versions behind but
would have to scroll over 8 irrelevant versions for every package they
upgrade. In my view, it is a bigger disservice to the user than having
the list be "reverse ordered".
Note whether "latest" can be "latest stable" with a dedicated section
for experimental or unstable compat versions separately. Personally, I
keep "latest known" in the top, so then people also get to read about
upcoming changes.
I would like to think it gives me feedback on upcoming changes before
I stabilize a new compat level. However, it is not clear to me to which
extent it works in that regard.
I would also recommend that you also describe how to opt-out of an
upgrade where the opt-out is trivial and possible. E.g., with
`Rules-Requires-Root` you could say "To retain the previous behaviour,
explicitly set `Rules-Requires-Root` to `binary-targets`".
For me, it is generally more valuable to have 90% to upgrade with
opt-outs than have 60% upgrade completely and have 40% that cannot
upgrade due to one feature they have not figured out how to deal with.
That is where the "opt-out" helps.
It is often also easier to spot the opt-out than it is to tell why
people are not upgrading (the documented method is likely going to be
copy-pasted verbatim in most cases). In that case, it will also enable
to get better feedback on which changes did not work so well for people
via codesearch (etc.).
With change like the `dpkg-shlibdeps` one, I would personally point
people to the `-l` option already in the upgrade checklist. Like "If you
have used LD_LIBRARY_PATH previously, then in most cases you want to use
`-l` in dpkg-shlibdeps (or via dh_shlibdeps's `-l` or `-L` options if
you use debhelper)".
That kind of guiding hopefully results in more people successfully
migrating - via the path you intended - with less user support landing
on your desk.
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
To me, dpkg-build-api looks like it follows a tried and successful path
and I suspect it will be successful as well.
As long as we have the layering issue, it can only complement
debhelper. However, I think complementing is completely fine. Even if we
never solve the layering problem, I still think having a pattern for
achieving improved defaults in dpkg over time is better than status quo.
All in all, I hope you will go ahead with this proposal.
Best regards,
Niels
Reply to: