On Thu, Jun 20, 2024 at 11:00 AM Gerardo Ballabio < [email protected]> wrote: > > I might have misunderstood Paul's questions. If so I'm sorry (if Paul > wishes he could explain what he actually meant), but I think that my > questions are relevant too.
I've been following the thread and haven't felt the need to get involved, the conversation has been interesting and a lot of what Ian was saying was stuff in the back of my head (for instance, the mega diff from the unnamed Linux vendor) when I was writing it. I was intending to point out that there's a bit of a gap we kinda skipped over in the other thread -- what "source" means; and specifically, if in conjunction with the tag2upload class of automation (but as y'all note, orthogonal to the discussion -- but not implementation) we need to revise how we handle sources. I'm not convinced we have an answer to the questions I was posing and I'm seeing a lot of real meaningful technical points of disagreement. I can't shake the feeling that resolving this would help guide implementation for something like t2u. If we (as a project) truly regard a .dsc/source distribution as an unfortunate intermediate build artifact that we wish to offload to a source buildd network, I have to wonder why we keep them around. If we want signed tags, may as well migrate to such a structure, and have the binary buildd network clone (where clone may mean dget the export of the git-archive? maybe real clone?) the related git repo and build off that. Is uploading an NMU by dgetting the .dsc, modifying it, and dputing the changed source polite these days? Is it something we want to encourage? Discourage? Should it happen in Git? > Do I understand correctly that, in reference to *my* questions, you > are saying that "the source is the current version"? FWIW, with half of an ftp hat on (since this is fairly unobjectionable and hopefully something we all know), we need to maintain source for every binary artifact we distribute in the archive. For instance, when we statically build, we need a Built-Using header so that dak will retain sources used to build that binary -- even if the .debs build directly from that source package are no longer in the archive. Beyond that, we have a social and moral question on our hands for what we want to do as a project. A question with real, actual tradeoffs. I have my opinions (both personal, Debian and ftpteam in so far as I count for each of those), but I don't think they're important to outline since I'm not the one doing the work or saying yes to things. I will point out that being able to rewrite history (as Ian said) is going to have to be a fact of life. Removing DFSG-nonfree files (e.g., an RFC checked into an upstream repo -- very common), changing upstreams for a API or CLI compatible fork/rewrite, or removing a deadname for a contributor are things I can see happening in such a world. It's just a constraint that we can work with -- good engineering is about constraints, after all :) -- :wq
