Re: RFC: New dpkg-build-api levels
Hi!
On Sun, 2023-05-14 at 10:25:19 +0200, Niels Thykier wrote:
> Guillem Jover:
> > 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.
Ah perhaps also the default paths for debian/files and
debian/substvars, AFAIR that didn't cause much concern, so I might
bring that up to confirm.
> 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.
Ack, done.
> 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.
Right, fully agree.
> 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.
Ack, I've tried to do this for the various options, and expanded what
some implied (the required rules targets). For the debhelper
reference, I'm always conflicted, because I recognize that this is
useful information, but it is also a layer violation (even though only
documentation-wise) and it feels wrong for dpkg to document how to use
debhelper. :/ So I've left that part out for now, it can always be added.
I've force pushed to the branch with these and other updates and
cleanups and fixes.
> 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.
Yes, agreed.
> All in all, I hope you will go ahead with this proposal.
I'll leave some more time for comments, but otherwise I think I'll start
merging the infrastructure in a bit. Thanks for the feedback!
Thanks,
Guillem
Reply to: