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) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ef1638.9020...@debian.org
