Re: [RFC] General Resolution to deploy tag2upload
Hi,
On Wed, 2024-06-19 at 11:18 -0700, Russ Allbery wrote:
>
> I think the main problem with 3.0 (native) without a canonicalization step
> for maintainer workflows is that it forces patches-applied. This is
> totally fine with *me*, since this is how I want to work on all of my
> packages, but as I recall from past discussions it is very much not fine
> with a lot of maintainers. Some folks really do want to directly maintain
> a stack of patches in debian/patches. This breaks with 3.0 (native)
> because 3.0 (native) turns off all the dpkg mechanisms to apply those
> patches. Now you have to add some goo to debian/rules to apply the
> patches during the build and we're back to the world of dpatch and I don't
> think any of us want that.
You can use 3.0 (native) for patches-applied without duplicating the
patches in d/patches and still use 3.0 (quilt) for patches-unapplied
with the patches in d/patches.
> So, I think this reintroduces the same problem with a different set of
> source packages and transformations: the Git tree doesn't represent the
> format of the buildable source package, and there's no way to easily
> provide dak with the final form of the source package because that has to
> be constructed by applying all of the patches.
>
> (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.
>
> 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.
> I think it's also a trade off in supported workflows. If we start telling
> people exactly how they have to use Git to work on Debian packages, we can
> simplify a lot of things, but wow do I ever not want to open that can of
> worms. Every time we open it on debian-devel, it's a giant mess. (Even
> more than this thread!)
We don't do that? There is no requirement to use tag2upload to do
uploads. Otherwise tag2upload already limits the set of supported
workflows.
> > Well, it doesn't change what package maintainers do as the purpose of
> > tag2upload is that package maintainers don't have to think about source
> > package representation? So changing those should not affect maintainers
> > much?
>
> I wish it wouldn't change what package maintainers do, but the only way I
> think that works is to interpose a relatively complex build step between
> the maintainer representation and the archive, which is exactly what we're
> currently stuck on.
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...
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. We should try to get rid of them to make it easier for
maintainers to specify their intent clearly.
Ansgar
Reply to: