On 29.05.19 01:39, Simon McVittie wrote: Hi,
> You might reasonably assume that, but no, they are not. mesa (and probably > other xorg-team packages) uses v1.0 dpkg-source format combined with > dh --with quilt, so deliberate Debian changes can be either direct > changes to the upstream source code, or quilt patches in d/patches, > or a mixture. Additionally, mesa uses d/source/local-options to ignore > files that only exist in the upstream git tag (which is what gets merged > into the packaging git branch), but not in the upstream `make dist` output > produced from that tag (which is used as the .orig tarball). hmm, sounds quite complicated ... anyone here who could explain why exactly they're doing it that way ? by the way: that's IMHO an important information we should also collect: why exactly some particular workflow was picked > My understanding is that this unusual difference between the .orig > tarball and what's in git is an attempt to "square the circle" between > two colliding design principles: "the .orig tarball should be upstream's > official binary artifact" (in this case Automake `make dist` output, > including generated files like Makefile.in but not non-critical source > files like .gitignore) and "what's in git should match upstream's git > repository" (including .gitignore but > not usually Makefile.in). Since we have git, I've completely given up the orig tarball - I'm just basing on their release tags. And, of course, there shouldn't be anything autogenerated in the git repo - always recreate everything (*especially* autotools-generated stuff). The orig tarball, IMHO, is a long obsolete ancient relic. For upstreams that don't have a git repo yet, I setup an importer first, and call that my upstream. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
