On Thu, Aug 29, 2019 at 01:26:08PM -0700, Russ Allbery wrote: > While this is not an argument against *ever* using 3.0 (native) or some > equivalent when packaging upstream software, I have found it to help > relationships with upstream considerably in the past to represent the > package as their software as released plus a set of Debian patches. [...] > There's also a psychological value for some upstreams to representing all > changes to upstream as patches. If they're worried Debian is doing some > weird nonsense (from their perspective) to their package, they can look at > debian/rules for build flags and then at debian/patches and see exactly > what we've done, and feel assured that the rest of the package is exactly > as they released it. That's easy for them to do; downloading the full > package and then diffing against their tree is more awkward and can't be > done with some casual web browsing.
Yes. In fact, not only upstreams, but in some cases downstreams and other people with a stake in how the package is put together. When I converted Debian's OpenSSH packaging to 3.0 (quilt), it was partly because a company using my packages was concerned about the difficulty about picking apart the changes in the Debian diff so that they could audit the logical changes that I was making; even though they were a large company with lots of highly-competent staff, just providing a public VCS that they could look through and pick apart the monolithic delta for themselves still turned out to be a prohibitively difficult barrier. Doing the work to provide cleanly-separated patches (which in many cases evolve over time) was a useful exercise for me and made things instantly much more comprehensible for them. This was a while ago, of course, but it was that experience that converted me to being convinced that providing broken-out patches in an easy-to-consume format is an invaluable service to our users. quilt itself is very much a lowest common denominator and I certainly think it's best treated as an export format from richer git history; but just exporting stuff from git without that annotation of logically-divided-up differences from upstream isn't an adequate substitute. > This is one of those cases where knowing your upstream is invaluable. A > lot of upstreams won't care in the slightest, some upstreams are Git > experts and know exactly how to get the data they care about, and others > are still using Subversion or even CVS and will find anything related to > Git opaque and frustrating. Some upstreams actively encourage downstream > modifications and will seek them out and incorporate them, some upstreams > are happily oblivious and only look at patches or PRs submitted to them, > and some upstreams will get actively upset at what they view as > unmotivated or incompatible changes and may require delicate handling > (part of which, in my experience, is effortless transparency so that they > don't feel like anything is being hidden from them). And also bear in mind the case where doing a git clone maybe takes quite a while over a slow network link, but going to salsa or sources.debian.org and having a quick look through debian/patches/ takes a fraction of the time and is all you need. -- Colin Watson [cjwat...@debian.org]
