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
