Re: [RFC] General Resolution to deploy tag2upload
Ansgar 🙀 <ansgar@43-1.org> writes:
> On Wed, 2024-06-19 at 11:18 -0700, Russ Allbery wrote:
>> (And in case you're now wondering whether tag2upload can just bifurcate
>> here and produce 3.0 (native) for patches-applied and 3.0 (quilt) for
>> patches-unapplied, I don't think that works either. There are yet
>> other cases that we haven't talked about. For just one example, I
>> believe one large maintainer team uses a combination of some changes in
>> debian/patches and some changes committed directly to the upstream
>> code. I personally would not do this, but it is supportable and
>> supported and they have their reasons for wanting to do it that way.
>> See dpkg-source --auto-commit.)
> Then those packages can't use tag2upload as is. That doesn't seem to be
> a critical problem as tag2upload doesn't support all cases anyway.
I feel like we're drifting back into "I'm okay with specific tag2upload
use cases that are trivial, but not okay with places where tag2upload is
doing real work for the maintainer" territory, which is where I thought we
were stuck on before Joerg said maybe we weren't.
The point is to support a wide variety of workflows and not impose a
workflow on the maintainer. The cost is a source package build step.
Maybe there are some workflows that can be supported without that, but
that's not the point; in the general and hardest cases, the build step is
required and the transformations are not trivial. The goal is that the
maintainer doesn't have to reproduce that step and sign the results; they
can sign a Git tag and let tag2upload do the work.
You and Joerg both sounded like you were considering accepting that.
Specifically, you said:
| A downside is that integrity verification and third parties (possibly)
| verifying the data falls flat. For me integrity verification would be
| somewhat nice and third parties a bit less interesting (given they can
| get the tag, compare files and possibly redo what tag2upload does if
| they also care about .dsc and stuff).
"Somewhat nice" is not "this is a blocking requirement." It's "I don't
like that we don't have this, but maybe there's some room here." So... is
there some room here?
We can argue back and forth about whether a source package build step is a
good idea or not for another hundred messages and I'm not sure that we're
going to manage to convince each other, so let's take it as given that you
are unhappy there's a build step here (that is not done by the uploader)
and would rather there not be.
Is this a hard blocker from the FTP team perspective? Or is there some
space here where tag2upload can do this build step for the uploader and
the FTP team will accept the resulting package, even though this is a
design that you don't like?
>> tag2upload canonicalizes all of this random stuff to 3.0 (quilt) with
>> specific predictable properties, which has some real and non-trivial
>> benefits for everything downstream that wants to analyze the archive.
> Some of this random stuff, not all of it.
The point is that it can keep adding more. It's a piece of software that
can be improved, including supporting the *next* good workflow idea that
comes up with that none of us know about yet. This is, from the
tag2upload development perspective, a truly vital decoupling.
> All these transformations remind me of running autoreconf to include
> generated configure scripts in the release tarballs. That is a
> relatively complex build step between the maintainer representation and
> the release. Running autoreconf at that stage has come a bit out of
> fashion, but I feel we talk about hanging on to that here...
We didn't eliminate running autoreconf, we moved it into the *binary*
package build system. The build step is still there, it just now happens
elsewhere. (In, I might note, a buildd whose output dak implicitly trusts
even though it's not signed by the uploader.)
I don't see a way to move the Git tree transformation into the binary
package build system because the interface to the binary package build
system is a source package and I'm trying to avoid boil-the-ocean changes
to the entire Debian architecture here. But, rather more to the point, I
don't understand how that would make anything more secure.
> I also think the maintainer should have a chance to know what actually
> ends in the source package that gets used as input by buildds. Complex
> transformations happening on a remote black-box do not make that easier.
The maintainer *can* run dgit locally, and I agree that the output of dgit
and tag2upload should match. The point here is not to make it impossible
for them to do that; the point is to remove the *requirement* that they do
that.
I do not look at the source package that dgit spits out, I just sign it
and upload it. I do not think that's a reasonable thing to expect me to
do, and realistically I don't think that's a thing that people are doing.
I don't read the configure script that autoconf spits out either, for much
the same reason. If we want to check the output of build systems, we need
reproducible builds, because humans are very bad at this, won't do it, and
won't find problems even if they do.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: