[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: R³ by default: not for bookworm

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?

⢿⡄⠘⠷⠚⠋⠀ ***** ***

Reply to: