On Fri, 28 Apr 2023 at 10:12, Luca Boccassi <[email protected]> wrote: > > On Fri, 28 Apr 2023 at 09:09, Helmut Grohne <[email protected]> wrote: > > So yeah, with the exception of dash, this looks fairly good. Let me also > > dive into dash. Unlike the majority of diverters, it diverts in postinst > > rather than preinst to allow controlling /bin/sh via debconf. A similar > > technique is in effect by gpr. In any case, this is special, because > > dash diverts its own files, so when moving dash's file, its diversions > > can be migrated at the same time. It merely means, that we cannot have > > debhelper just move files (as that would horribly break dash) and > > instead have to move files on a package-by-package way. We could also > > opt for removing dash's diversion in the default case and there even is > > a patch for doing so (#989632) since almost two years. Too bad we didn't > > apply it. In any case, as long as the file moving is not forced via > > debhelper, dash should be harmless. > > If I understand correctly, by "forced via debhelper" you mean the > proposal of fixing the paths at build time, right? But if not via > that, it means having to fix all of them by hand, which is a lot - is > it possible to fix dash instead? Or else, we could add an opt-out via > one of the usual dh mechanisms, and use it only in dash perhaps?
Also as pointed out by the maintainer the debconf machinery was dropped from dash, last year: https://salsa.debian.org/debian/dash/-/commit/c322a1c9fc6be11d7eb4439 This should hopefully simplify things? Kind regards, Luca Boccassi
