On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote: > This history has at least one commit per upload, although ideally > has the package maintainer's full revision history and upstream's > full revision history.
I understand you like the history. A lot of people do. But not everyone values it, and I don't. The only uses I've found for it are git-bisect, reversing hasty deletes, and auditing who contributed what which is a handy weapon in a court room copyright battle. I can count the number of times I've done all of those things in my life on one hand. Regular backups do those jobs almost as well, and I have to do them anyway. Source code control becomes a real time saver when you have a lot of people working on the same source - I'd go so far as to say indispensable for that case. Such merging of histories needs a small amount history to work with of course, and that makes that small amount of history equally indispensable. However the typical Debian Developer scenario of the "lot of people" being you and upstream is a fairly degenerate case, so their is understandably get some argument about whether a heavyweight tool like git adds much. If you like it that's great - but others thinking it's not worth the bother is also great. I doubt anybody who just wants a one off copy of the source is going to see much in the way of greatness. On Tue, 2019-10-22 at 20:21 -0700, Russ Allbery wrote: > I don't agree with this definition of reproducibility. You're > defining reproducibility from inputs that I consider build artifacts, > which to me is rather weird. That's a perfectly understandable perspective from a Debian Developer. But lets take a different perspective, or a Debian user installing audited-crypto-program-x. What you are dismissing as "artefacts" is exactly the information the person installing this needs to assure themselves the Debian version of audited-crypto-program-x is a reasonably faithful reproduction of the original. If the packaging is done well it will be broken down into small changes, each with a documented purpose. (None of this is rocket science or new, we are fairly close to it now. One the reasons I am writing this is it would be if better - and definitely not get worse at it.) The point of defining the process of constructing the Debian source representation as a "pure function" is to guarantee it faithfully reflects the original source for and documented changes _only_ - not some random crap living in stale state carried across from years ago. From my perspective there are lots of ways a Debian developer could store this stuff. Quilt patches with their headers are one and they work well enough from this perspective - but a Git repository with branches representing those same changes works equally well, although it would be nice if a git branch (as opposed to a commit) could have a rant associated with it about why it is there akin to the quilt patch header. (I guess this would be trivial to add by insisting each branch adds a description file to the debian/branches directory.) The Debian developer is free to use whatever representation works best for them, so long as when I download it, I can easily see the debian version of openssl contained a patch that changed random number its generator to getpid(), along with the reason why. AFAICT, dgit does not address this, at all. It's written purely from the perspective of the Debian developer.
signature.asc
Description: This is a digitally signed message part
