On Wed, Feb 01 2023, brian m. carlson wrote: > [[PGP Signed Part:Undecided]] > On 2023-02-01 at 09:40:57, Ævar Arnfjörð Bjarmason wrote: >> "A spec" here seems like overkill to me, so far on that front we've been >> shelling out to gzip(1), and the breakage/event that triggered this >> thread is rectified by starting to do that again by default. > > Sure, that will fix the immediate problem. > >> But so what? We don't need to make promises for all potential git >> implementations, just this one. So we could add a blurb like this to the >> docs: >> >> As people have come to rely on the exact "deflate" >> implementation "git archive" promises to invoke the system's >> "gzip" binary by default, under the assumption that its output >> is stable. If that's no longer the case you'll need to complain >> to whoever maintains your local "gzip". > > I don't think a blurb is necessary, but you're basically underscoring > the problem, which is that nobody is willing to promise that compression > is consistent, but yet people want to rely on that fact. I'm willing to > write and implement a consistent tar spec and to guarantee compatibility > with that, but the tension here is that people also want gzip to never > change its byte format ever, which frankly seems unrealistic without > explicit guarantees. Maybe the authors will agree to promise that, but > it seems unlikely. Maybe they won't, the point is that an upgrade of git wouldn't break github in the way that's been observed, instead that potential breakage would happen whenever the OS (or whatever's providing "gzip") is upgraded. So, if gzip promises to never change such sites can upgrade it without issues, but if it does they'll presumably need to pin it forever. And those sites that don't care about "git archive" stability can use whatever their local "gzip" is, without caring that the output might change. >> If we wanted to be even more helpful we could bunde and ship an old >> version of GNU gzip with our sources, and either default to that, or >> offer it as a "--stable" implementation of deflate. > > That would probably break things, because gzip is GPLv3, and we'd need > to ship a much older GPLv2 gzip, which would probably differ from the > current behaviour, and might also have some security problems. We're way off in the realm of the hypothetical, I don't think we need a gzip fallback, we can make it the issue of the rare downstream user who needs such stability. But if we shipped a last-good gzip my understanding of software licensing is that we could ship the GPLv3 version. The issue with combining GPLv3 and GPLv2 works is if you do something like upgrade our wildmatch.c to the GPLv3 version (ours is derived from an older GPLv2 version). Then our combined work is derived from two different licenses. But if you're just invoking a different process those two sources can use incompatible licenses. There's established precedence for that throughout the industry, and it's the FSF's position on the matter. So if we offered to build a gzip for you from GPLv3 sources shipped in-tree that wouldn't infect the rest of git's GPLv2 code, any more than Debian shipping both git and gzip is cross-contaminating the two. It might cause us some hassle with distributors for whom any mention of GPLv3 is anathema (e.g. Apple), but I understand that that's general paranoia about its patent clauses impacting the distributor, not a license incompatiblity.
