On Sun, Sep 18, 2022 at 03:58:57AM +0200, Guillem Jover wrote: > On Sun, 2022-09-18 at 03:39:43 +0200, Adam Borowski wrote: > > A few packages had a value of R³ other than "no" / "binary-targets", > > these are deprecated now; bugs filed. > > Deprecated by who or what?
I had the impression https://bugs.debian.org/975637 has passed. > > The process of adding/changing a field in "control" differs between the > > three source formats we have. > > Hmm, I'm not sure I understand this statement. In 3.0 formats, you can unpack a tarball (whose name differs by format), update debian/control, repack -- no need to apply the quiltage or touch any other fragile bits. In 1.0 you need to go through all the motions -- I don't even see (in dpkg-source's man page) how to skip running "clean" which in turn requires B-Deps and can fail. > > Of these, the most involved format is 1.0 -- you need to repack the > > whole source. And quite a bunch of packages fail that step, not even > > letting me to modify anything. I guess FTBS bugs need to be enforced... > > Nor this one. Could you give more details? Fails To Build Source. Ie, ｢dpkg-source -x｣ then ｢dpkg-source -b｣ fails. I tend to use sbuild for repacking, the whole incantation is: alias sbuild-source='sbuild -s --source-only-changes --no-arch-all --no-arch-any --no-run-autopkgtest' > > Almost any format 1.0 package with R³ unset does so not because of an > > actual need for fakeroot, but because of an ancient build system and a > > decade or two of neglect. > > Lack of debhelper/dh usage certainly makes adding the field more > challenging, yes. Another common error are hardcoded whoami checks. > > Format "3.0 (native)": > > The complete list of packages that FTBFS if you set them to R³:no is: > > Format "3.0 (quilt)": > > In a pile of build logs that looks incomplete: > > 408 Status: attempted > > 12387 Status: successful > > Thanks for these checks! But in addition to checking whether these failed, > did you check that they ended up with the same user:group and perms (such > as SUID), as before setting the field? I only checked whether they build; that'd be the next step if the change to the default looked plausible. > > Thus: let's revisit R³ being required after Bookworm. > > My current thinking though, has been to change the default via something > like: > > <https://wiki.debian.org/Teams/Dpkg/Spec/DpkgDevCompatLevel> Adding a yet another field everyone has to bump would be costly in human time. I wonder, perhaps it'd be better to hijack dh compat -- at the cost of a bogus b-dependency for a small fraction of packages? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ ***** *** ⠈⠳⣄⠀⠀⠀⠀
