On 08/19/2014 04:40 AM, Jeremy Stanley wrote: > For a variety of historical and pragmatic reasons, many distribution > channels expect a release tarball to contain some information which > is more efficiently stored in VCS metadata (authorship, detailed > change information, version numbers, et cetera).
Well, for the changelog of OpenStack stuff, the FTP masters have express their opinion that it's just too big to be in every packages, so I have to *not* include them. As for the AUTHORS file, it isn't helpful at all from a package maintainer stand point. What's important is who is the copyright holder, and this should go directly in debian/copyright. To this day, I have no way to have that file fully right, considering how many contribution there is in OpenStack. I've raised that issue on the OpenStack dev list, but I don't think my message went through the correct way. Anyway, my choice is just pragmatic: it's more convenient for me to do things this way, and for the moment, the convenience outweighs any other issue (the only issues I had was wrong MANIFEST.in, which I have patched). > I think this is twisting DFSG #2 pretty substantially to claim that > a tarball containing a few additional autogenerated metadata files > from a make dist step is somehow less free than one created by > tarring up files directly out of a VCS branch. If upstream's VCS > really is "the preferred form for modification" (which BTW is > wording borrowed from the GPL and doesn't appear in DFSG #2 > directly), then Debian is effectively *not* distributing the > preferred form regardless--the currently accepted source package > formats in fact make that impossible (format 3.0-git went nowhere > due to ftp-master review concerns, and even it still used tarballs > for its underlying file archive though that was more of an > implementation detail). You could use debcheckout. It works very well. So in a way, we do ship both forms, and even that the Git form is the preferred one. Also, something that strikes me. If I follow well: - upstream publishes a Git repository. But I shouldn't use it. I should use a tarball - which tarball I then should somehow (with many issues already mentioned in this thread, with pristine-tar and all), store in the Git repository, to make it easier for contributors and users to deal with source packages. - Then somehow, we should be able to regenerate the saved tarball from the Git on Alioth. That's really cumbersome. I prefer to skip (IMO useless) steps. Why not simply accept that it's ok to also use upstream git? These are the same sources that we're talking about, after all. >> Shouldn't all what upstream generates in the release tarball also >> done by the Debian package build anyway? > > You're free to do so (is regenerating authors lists, changelogs, et > cetera during package build really worth the effort?) Please name the "et cetera". Because it is my understand that it is the only thing I would "miss". > If you repack an upstream tarball, isn't it convention to > annotate the version you're claiming on it to indicate it's been > repacked (and include a readme.source file or similar documenting > your repacking methodology)? I'm merely suggesting that if you're > going to generate "original" tarballs from VCS contents then they > should be treated in a similar fashion as a repacked tarball in that > regard. If you think that's a problem, then I can add such a README in all of the packages I maintain this way, no problem. Altering the version string would be annoying though (I'd have to retag after each "git fetch upstream"), but if you insist really a lot, I may consider it. It will just take me a *long* time to write the READMEs though (since there's more than 100 packages which I maintain this way), but I think it's a good idea. > As already mentioned in my message to which you're replying here, > it's understandable that you might generate substitute tarballs > out of a VCS when there is no corresponding release tarball, for > example when packaging development snapshots. However reinventing > upstream's dist steps to make the tarball you eventually end up > using in your source package anyway seems like a duplication of > effort. For the moment, it's been effortless (apart from the few glitches with the MANIFEST.in, which I mentioned earlier). The fact that it's less effort than managing tarballs from upstream is the main reason why I'm doing things in this way. Even if you don't like it, I hope you'll understand my point of view as someone who is largely overloaded with the amount of things to do for packaging OpenStack in Debian. >> 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. > [...] > > I recall it suggested on Debian mailing lists and other > howtos/articles even in very recent years that to be a "good > upstream" you should release tarballs and publish signed release > announcements including their checksums, and that upstreams who only > "release" software as a tag in a VCS are making things harder for > everyone downstream. Pretty much all the projects on which I do > upstream work provide these things because they have been explicitly > requested by distribution packagers. Well, as you see, not everyone agrees! :) > If the modern trend is to just assume that nobody upstream will > bother to release tarballs any longer and expect every distribution > to do it themselves only slightly differently, then I should revisit > those assumptions and perhaps no longer bother. Is this a generally > consistent opinion across Debian package maintainers now? Across > other distributions as well? I don't think there's consensus, no. Not in Debian at least. >> 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. > > Makes sense. So then why does Debian (and for that matter so many > other distributions outside of the *BSDs) base source packages on > tarballs rather than building binary packages directly out of a VCS? > It seems a contradiction on the one hand to assert that you don't > need tarballs any longer but then on the other hand still rely on > them completely. Well, there's "apt-get source", but there's also "debcheckout", which these days, a lot of people use. So we do publish both! apt-get source even warns you about that fact. The only thing is that we don't have multiple mirrors of VCSes, and it's a lot more easy to have mirrors for static files. Also, there's many packaging workflow with git, and it may not be easy to double-guess what the maintainer is doing. This very thread is about standardizing it, and I think it is the right thing to do. Thanks Raphael for opening the topic! By the way, I haven't wrote that "[we] don't need tarballs any longer", it's just *my* personal preference (which others apparently also share) to use upstream VCS directly. YMMV. :) 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/53f395af.40...@debian.org
