Ansgar 🙀 <ans...@43-1.org> writes: > On Wed, 2024-06-19 at 14:43 -0700, Russ Allbery wrote:
>> I don't think it's bad in any inherent way, but it's not tag2upload. >> It's not the thing that the developers have been working on, it doesn't >> solve the problems they're trying to solve, and it doesn't let people >> use the workflows that they want to support. > You basically say "nothing would work at all". > Is any change a hard blocker from the tag2upload team perspective? Or > is there some room for changes, even though it would be a design that is > not identical to the one currently proposed by the tag2upload > developers? The piece that the tag2upload developers are asking for is the ability to move the source package build step to a project server so that the uploader doesn't have to do it. This requires that dak accept a *.changes and *.dsc file signed by tag2upload, and it requires that the uploader not have to do the source package build step locally. I think we're now past the first part, but we're still stuck on the second part. (Or at least you and I still are, and maybe Joerg is okay with this? I'm not 100% sure.) Not having to build the source package locally, and that includes building the tree of files that go into the source package locally, is what makes the whole thing useful. Without being able to do this, it doesn't really have a point. We already have a system that lets the uploader build the source package locally. The point of tag2upload is to not do that. I appreciate that you're trying really hard to find a way to represent the Git tree directly in a source package so that no build step is required and building the tree of files locally is trivial. I understand that you truly think that this accomplishes the same goal with some acceptable lossage around the edges. But it doesn't; it's missing the point. The point is that there are a wide variety of potential transformations between the Git tree and the source package required to accomodate the range of Git workflows used in Debian today *and tomorrow*. Having a source package build system in the middle is what allows us to *decouple* the workflow from the build output so that people can use the workflow that works best for them and we get standardized Debian source packages out the other end. I think we've found potential compromises to a number of other things already: * The most recent design had tag2upload as the only verifier of the signature on the Git tag, and I think we found a plan for that to not be the case that everyone is happy with. * It sounded like you might want more metadata in the tag. I don't think that will be a problem if it's metadata that's easy for the uploader to add, like the target suite. * There was an objection to the object signed by the uploader not being in the archive. I think that's solvable if you are okay with publishing the signed Git tag object in some form in the archive. I suggested a bunch of other things earlier that were already changed in the design. If we go back to the 2019 discussion, there have been more changes. There's a lot of willingness to adjust here. But the key design point has always been that tag2upload builds the source package and the uploader doesn't have to. I think we're now at "well, that's fine as long as the uploader can build the source package file tree locally." That *is* a compromise, absolutely! We've at least gotten the *.dsc file construction out of the picture. But the number of workflows that can be supported under that restriction is extremely limited without making the uploader build the source package locally, still. It might be useful for some relatively simple cases, but it doesn't move the source package build step to a Debian project infrastructure system and it still requires that the uploader build the source package file tree locally. At the risk of trying to argue by analogy, it feels akin to saying "okay, you can have a binary buildd, but only if it doesn't use a compiler and only copies files around." Yes, that's a compromise compared to no binary buildds, but in a way that makes the whole picture more complicated and doesn't achieve the point of the design. > Because from my perspective it mostly looks like us like ftp-master > willing to find some compromise, but the tag2upload side hard blocking > on any possible change. Well, first, I don't think this is true, but second, the designs proposed so far that you've said that you would accept (maybe not including Joerg's message?) all involve not doing exactly the thing thing that tag2upload is designed to do. I'm not assuming that this is how you are thinking of it. I think there has been a lot of confusion about what the point of tag2upload is, and that's why I keep explaining it in different words because sometimes it really is hard to grasp the essence of what someone is asking for. (That's also why I'm trying to do a lot of the writing here; I have a lot of patience and it's easier for me to do this because I'm not personally invested.) But some features of a system really are integral. You can't compromise absolutely anything and still have a coherent design that does something useful. "I think a bicycle should have no wheels and you think a bicycle should have two wheels, so let's compromise and give it one wheel" does not produce a bicycle. It produces a unicycle. This might be a useful device, but it's not a compromise bicycle. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
