Guillem Jover writes ("Re: Bug#1092193: option (or env) to request <=bookworm
r-r-r behaviour"):
> As a heads up, please read my reply more as an exploratory one with
> a pinch of push back,
Thanks for the attention. I'm going to reply in the same spirit.
I want to emphasise that I am trying to persaude you not because this
issue is in any way a problem for me or for src;dgit. Sean and I can
do something else in our tests.
I'm trying to persuade you for the benefit of our users - distant
users, whom I feel we have a moral obligation to. Really, *your*
useres (some of whom may be using my software too, but that's wholly
irrelevant since there isn't any meaningful interaction).
So if you decide not to provide this option, I will be *sad* for our
users, but I won't be *inconvenienced*. I'm having this conversation
for distant users' benefit, not mine.
> 1) chown fails w/ checked exit code, aborts
> 2) chown fails w/o abort, silent breakage
>
> In here chmod (say to set-user-ID) does not matter because the chown
> success or failure always wins.
>
> So for the problematic case 2),
I think build failures are problematic too.
Also, I think you're missing a category of possible failure modes.
With "Rules-Requires-Root: no", the "build*" target(s) are skipped.
Packages *ought* to cope with this, so that "binary*" does the work.
But packages that aren't using the dh sequencer can easily have such
bugs.
One piece of background that is heavily influencing my thinking is:
It is easy, when working within Debian, to radically overestimate the
likely quality of non-Debian packages. I have done some work with
packages in the rpi ecosystem (I'm thinking of packages *not* part of
Raspbian, which has source from Debian), and also other upstreams.
My experience is that packages written by people not steeped in Debian
culture, and that aren't subjected to Debian's various QA processes,
often only resemble normal Debian practices in the vaguest sense.
This is to be expected. Debian packaging is complicated, and can be
weird. People working outside Debian are just tryilng to get shit
done and don't have time to learn how to do it properly. They hack
something together until it works.
As the upstream for the tools, I think we ought to be kind to those
users. That means that when we break things (for good reasons, as
here) we provide escape hatches, compatibility modes, etc., so that
our downstreams can fix things on their schedule rather than ours.
> Said that. It's true that packages can of course still break (either
> with an abort, or with a dpkg-deb warning), but an extremely quick and
> backwards compatible way to unbreak them would be to add an
> «Rules-Requires-Root: binary-targets», which should do the right thing
> even with old dpkg-dev tools that do not understand it (as then it would
> be the default).
That requires modifying the package. That's probably fine if one is
doing ad-hoc work on one (perhaps old) package, which one expects to
modify anyway. But there are many other scenarios.
Some downstreams and users will have their own build processes.
CI jobs, rebuild robots, and the like, which build packages
automatically. In such a scenario, an option or env var to restore
compatibility with existing packages, without having to add a step to
the build to mess with the source package, will be very helpful.
> Note that when we designed the R³ interfaces and behavior we took care
> of defining them so that new packages declaring these interfaces,
> after having been adapted, should still work with old tooling.
When trying to work with old code (or a mix), it is often the best
approach to try to use the newest tooling where possible. Normally,
tooling developers try to avoid breaking stuff.
(C and C++ compilers are indeed a notable exception. But C/C++
compilers are nowadays rightly notorious for being absurdly
user-hostile. We shouldn't follow their example.)
> This is the part I'd like to apply this slight push back. :) I don't
> think we can guarantee to build old packages with new tooling,
No, we don't promise it. But IMO we ought to support it - at least,
unless it's a great deal of work, or has other problems. The option I
propose is very simple, and I don't understand what the downside is.
(Unless, of course, the idea is to punish people for doing it wrong.
I mention this only because I've sadly seen, elsewhere, such hostile
attitudes, and I wanted to explicitly name a pathology that I think
we're all trying to avoid.)
> While I agree it's important to have ways to back off from a change,
> to ease with such transitions, in this case we have provided that
> already from the beginning. And what matters most is not failing
> silently.
I'm not sure what "way to back off" we have provided *to our
downstreams, working with out-of-Debian packages*. As far as I can
tell, the first these people will know about it is broken builds.
(I'm assuming they're not following highly-technical Debian-internal
discussions. And I don't think "modify all the packages" is a good
answer, at least, not on an enforced timescale.)
> I thought I could propose for dgit to use only this option
What? Certainly I do not intend for dgit to pass this option.
That would be entirely crazy.
I *do* think that *if* we have this option in dpkg-buildpackage, it
might be a useful, if somewhat unprincipled, workaround *in the
specific test cases in dgit's test suite*. Those test cases are very
pernickety and, by their nature, rather fragile. But, it would be
almost as easy to just change the weird test package.
So, in summary, please disregard the question of dgit when considering
this dpkg-buildpackage change request. dgit is not going to pass this
option. We may abuse it in a few (bizarre) test cases, but that's it.
> I was going to say I don't think I understand how this interacts badly
> with dgit, but from your thread with Niels, it looks like dgit might
> need to be changed anyway if it's doing tests based on incorrect
> assumptions, so this part is probably not very relevant anymore?
I think the dgit test suite situation is a red herring for this
discussion. The dgit test suite failure is why I looked at how
dpkg-buildpackage was changing.
But, having looked at how dpkg-buildpackage was changing, I feel we
are at risk of doing a disservice to downstream users. That is my
sole motivation here in this bug report.
It's particularly bad because those downstream users who will suffer
at the ones least able to cope with the problem. They're the ones who
are most distant from Debian, with the least knowledge and the fewest
helpful social connections to Debian experts. (They're already users
Debian sometimes supports rather poorly.)
Ideologically, I want *all* computer users everywhere to be able to
modify the way their computers behave. My goal when working on Debian
is to help make that possible. That includes users I don't know, and
it includes distant users who don't have all the relevant information
and skills and who may have done some broken stuff. We should try to
make the software we supply easy and forgiving.
Certainly, we should make our software easy and forgiving when it
doesn't compromise the quality in other ways.
I hope this explains my thinking.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
