1. Forum
  2. Usenet
  3. LINUX.DEBIAN.DEVEL

  • Re: =?utf-8?Q?R?= =?utf-8?B?wrM=?= by default: not for bookworm

    From Guillem Jover@21:1/5 to Adam Borowski on Sun Sep 18 04:00:01 2022
    Hi!

    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?

    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.

    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?

    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.

    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
    6 Status: failed
    32 Status: given-back
    15 Status: skipped
    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?

    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>

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Adam Borowski@21:1/5 to Guillem Jover on Wed Sep 21 13:00:01 2022
    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)