Re: Survey: git packaging practices / repository format
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
info@metux.net -- +49-151-27565287
Reply to: