Re: Standardizing the layout of git packaging repositories
Hi Jeremy,
I don't agree with you on this one. Let me explain why.
On 08/16/2014 07:05 AM, Jeremy Stanley wrote:
> On 2014-08-16 01:15:45 +0800 (+0800), Thomas Goirand wrote:
> [...]
>> Yes. Producing orig.tar.xz out of upstream tag should be industrialized,
>> and written in "some" tools, which we would all be using. I currently
>> do: ./debian/rules gen-orig-xz, but that shouldn't be specific to my own
>> packages.
>
> However upstream may build tarballs through a (hopefully
> repeatable/automated) process at release time, publish checksums and
> signatures for them, et cetera and prefer packagers use those as
> the original tarballs for official release versions.
And then? If I prefer to use their git repository, and create my own
orig.tar.xz out of a signed git tag, what is the problem, as long as I
use the tag they provided by upstream?
> I understand
> needing to create "original" tarballs yourself in cases where there
> are none (for example making development snapshot packages), but
> when upstream provides them it seems like it would make sense to use
> those tarballs in lieu of trying to recreate your own from tags in
> their version control system.
Why?!? Is there some sort of religion around tarballs? Shouldn't it be
the same stuff that "git archive" does? If it isn't, why is this the
case? Shouldn't one be able to use what's in the Git repository anyway?
Why can't it be fixed? Aren't we supposed to "build from source" anyway?
Isn't the upstream git repository the "preferred form for modification",
closer to what someone should be using when contributing upstream? Why
is it the case that upstream prefers that we use something generated
from his git repository? Shouldn't all what upstream generates in the
release tarball also done by the Debian package build anyway?
Also, what if I need to build a Debian package out of an upstream
commit, because there's some bug fixes which I need, but there's no
upstream tarball available?
- In my case, I'd just tag with something like this:
2014.2~b2+20140816+git+11ed391c. Then I'll use my standard process to
generate the orig.tar.xz (which is: doing nothing but editing the
debian/changelog to match that tag, and my jenkins script will do the
rest for me, ready for testing...).
- If doing what you're proposing, I'd have to manually create the
tarball, upload it somewhere (which could be *very* slow from where I
live), etc.
> I have become increasingly wary now that more and more slipshod
> upstreams with no release process have created a need for package
> maintainers to fabricate one on their behalf, the kludge can get
> turned back around on upstreams with formal, traditional release
> processes and used as a convenient excuse to discard their output in
> the name of consistency.
If by "traditional release process" you mean wasting human time,
computer CPU, and network bandwidth, to build old 80ies fashioned
tarballs (that is: with .gz compression and no PGP checksums), which by
the way loose all the commit history and such, I am wondering what you
are worrying about. That's useless these days, if upstream is using Git.
A tag is enough, and it's even better.
> *Please* don't replace upstream's release
> tarballs just because they have a VCS.
Generally, upstream don't provide checksums, even less provide PGP
signatures, while tags in git repositories are often pgp signed (and I
collected a bunch of signatures already in my ring). And often, upstream
include in the tarball artifacts which we do not need, like generated
files and so on. In the case of Python modules, for example, stuff from
PyPi often contains the egg-info folder, which we do not need in the
orig tarball (it's in fact preferred not to have them, because they will
be generated at build time anyway, with possible difference from the
tarball, which is in the way of a 2nd rebuild). Also, the .gz
compression is sooooo 80ies. We're in 2014, and it's still hard to find
upstream releasing with .xz compressions.
I also think it's best to be able to build from the git repository
rather than what's been generated out of it, because that's what you
will do if you want to contribute to the upstream project.
Last, it's extremely rare to have issues with upstream git tag. In the
case of OpenStack, the only small issues I had were with the MANIFEST.in
which is sometimes missing some file. But a small Debian specific patch
gets rapidly rid of the issue. Also, to some degree, this is a problem
upstream that should be fixed anyway.
So yes, please do generate orig.tar.xz out of PGP signed tags, and do
Debian git-buildpackage based on tags repository, using the upstream git
repository as source. That's the correct technical thing to do, and you
wont regret it! As an upstream: please accept progress and convenience.
Cheers,
Thomas Goirand (zigo)
Reply to: