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!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ ***** ***
⠈⠳⣄⠀⠀⠀⠀
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)