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
