Ansgar 🙀 <ans...@43-1.org> writes: > On Wed, 2024-06-19 at 08:39 -0700, Russ Allbery wrote:
>> Sure, we could tell people to use 3.0 (native) for everything with >> Debian changes to the upstream source and stop trying to use 3.0 >> (quilt). You're not the first person to make that suggestion, and it >> has some real merit for simplicity of representation of source >> packages. > Yes, it is both simpler and allows for more integrity guarantees. Yes, agreed, 3.0 (quilt) is very complicated under the hood. The simplicity in 3.0 (native) comes from discarding information (specifically what bits come from upstream and what bits were added by the Debian packaging), but if that's information you're fine with discarding, it's at least worth thinking through what the implications would be. 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. 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.) The whole reason why dgit exists is that the checkout of Git HEAD has widely a varying relationship to the source package contents depending on the maintainer workflow, and forcing it to be in any one form on the maintainer's system breaks workflows that some group of people feel strongly about. I'm not sure there's any way to dodge around that problem. We either need a relatively complicated source package build step, or we have to start telling people that they cannot use the workflow that they want to use. I don't have a lot of appetite for the latter. > Other ideas like waldi's 3.0 (gitarchive) also go in that direction. Similarly, I'm not sure a source package based on Git avoids the need for a source package build system. There are a ton of ways that maintainers store things in Git, and I'm not sure it makes sense to upload all of those as-is. The things that break are slightly different, but, for instance, some maintainers do not want the upstream source in the same branch as their Debian packaging files. You may have to add quite a lot of unwanted complexity to 3.0 (gitarchive) to represent those cases. Or reintroduce a source package build step, in which case we're back to where we started. 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. > I'm interested what other ftp-masters prefer when considering a trade > off between space and additional integrity guarantees here. I have a > preference for the integrity side. 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!) > 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
