(Trimming down the cc list because I think the topic in this corner of the thread is different.)
Bastian Blank <wa...@debian.org> writes: > On Wed, Jun 19, 2024 at 11:18:36AM -0700, Russ Allbery wrote: >> 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. > Do you have some examples of weird things? patches-applied vs. patches-unapplied is a big difference and I'm not sure you want them both in the same source format, let alone variations where patches are partly applied. Separate branches for Debian and upstream files as mentioned. There are doubtless a bunch more that I'm not thinking of. This is my own fault for opening the door, and I'm sorry to do that and then immediately close it again, but it's all that I can do to keep up with the discussion of whether we can enable tag2upload as already designed. If I get into a discussion of how to design a future different Git-based source package format, it's going to make this thread even more unwieldy and I'm going to drown. I don't think these two things are related, so I'm going to try to duck out of this conversation. I do care about this! But I think it needs a separate conversation. If we eventually get a Git-based source format, lots of things could in theory change, including how tag2upload works. But I remember what it took to introduce 3.0 (quilt) and I don't think we're going to get a new source format in any near-future time frame. Maybe I'm too cynical, and I will be delighted to be proven wrong. > But why would tag2upload need to support them? It is something new, it > can tell people: we support the following, use it or not. It already *does* support those workflows, if it's allowed to be deployed. People want to use them, and therefore they're supported. I don't think people are realizing just how restrictive the requirement that all the files in the source package be present in the working directory is. This doesn't only prohibit the work that tag2upload does. It also prohibits a bunch of what dpkg-source does, including all non-native 1.0 packages, --single-debian-patch, --auto-commit, etc. If the only thing that tag2upload is allowed to support is the cases where the source package is built by just tarring up the Git working tree, there's not much point to tag2upload. That's not where the important problems are, it has no future flexibility, and it is going to fail in all sorts of packaging scenarios that are commonly seen in Debian. > IMHO it is one of the problem of Debian that we fail to move forward. I think part of what is going on here is that there are profound disagreements over what "moving forward" looks like, and people are not going to all agree on the right approach. This is similar to Git workflows: we have a ton of them, not because people are ignorant and haven't seen the better workflow, but because people truly disagree over the correct workflow to use for their problems. One way to solve that problem is to say "we're going to pick one way to do things and you aren't allowed to do it the other ways whether you want to or not." Sometimes that's appropriate. But sometimes we can instead say "there are a lot of different ways to do software development, and there is a lot of personal preference and diversity of use cases involved, but we can canonicalize them after the fact so that we can support a bunch of them without breaking things." -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
