Please add some example to man pages, particularly concerning pristine tar workflow. Bastien Thank you Debian Release: wheezy/sid 500 unstable lcg-heppkg.web.cern.ch 500 unstable ftp.debian.org 500 testing ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed =======================-+-=========== git (>= 1.7.0) | 1:1.7.5.4-1 dpkg-dev | 1.16.0.3 Package's Recommends field is empty. Suggests (Version) | Installed =========================-+-=========== devscripts | 2.11.0
Hi Bastien, Do you have some particular examples of things that aren't clear in mind? The basic idea of gitpkg is to _not_ tie you into any particular workflow, ie. you just use the standard git tools however works best for a particular project, and so long as you can identify a treeish that corresponds to the debianised source you want to export (and one for the orig source if you need to export that also), then gitpkg can make you a source package of it, regardless of what workflow you used to create that repo, or even if you changed workflows somewhere along the line ... This means you can use it with upstream repos, or other people's repos, without requiring them to know anything at all about gitpkg in advance. If you enable the pristine-tar-pre-export-hook (as described in the man page), then when you nominate the treeish for your debian revision, the correct pristine tarball will be exported as the orig. To create the pristine tar commits in the repo, you likewise just use pristine tar as per its own instructions. I'm happy to clarify anything in the docs that isn't clear about that, but you'll have to help me out and point a bit more explicitly, since it's already fairly verbose, and I thought it did already cover most or all of this? (of course I'm the wrong person to judge that, as I already know too much about how it works, so suggestions are welcome.) Cheers, Ron
You only need to put a pointer to pristine-tar documentation or to get an example workflow. I needed to check the source how you export the tar.gz using pristine-tar and what parameters (particularly delta) you pass to pristine-tar. Moreover could you emphasize the need to select the good hook in order to use the good compression method. If I had pristine-tar a tar.bz2 i need to set the gitpkg.orig-compressor config. I forget to add it and it fail Bastien Debian Release: wheezy/sid 500 unstable lcg-heppkg.web.cern.ch 500 unstable ftp.debian.org 500 testing ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed =======================-+-=========== git (>= 1.7.0) | 1:1.7.5.4-1 dpkg-dev | 1.16.0.3 Package's Recommends field is empty. Suggests (Version) | Installed =========================-+-=========== devscripts | 2.11.0
Ah, so this isn't actually a "documentation bug" then ... It's really a real bug, or rather really two real bugs if you consider that both gitpkg and p-t are affected by the same issue ... You are correct in that at present the gitpkg.orig-compressor must be set to match the type of file you are expecting p-t to export -- but that said, requiring you to set that manually for this case is quite wrong. Doing so would then mean that for repos which started with tar.gz p-t imports, and later switched to some other compression format, you would have to manually reconfigure gitpkg.orig-compressor again before exporting older versions, and also mean that other users would not be able to export your packages without also first configuring that option correctly for the version that they wish to export. It's not entirely surprising that both gitpkg and p-t have been caught out by this, since they both existed before multiple compression formats were supported in the archive - but we do need to do something better than just formalise the current bad situation in the documentation. For gitpkg alone, this shouldn't be hard to fix, the gitpkg.orig-compressor option is really only intended for _creating_ a tarball that was exported from the git repo as a raw upstream source. So gitpkg should just ignore it in the case where an orig is already present and not being exported. What to do about p-t is a little less clear though, since unless I am mistaken it requires us to specify the full name of the tarball (including its compression type) before it can export it. But what we really want is the opposite of that - we don't really care what the compression type is, we just want it to export the tarball it recorded as corresponding to the version that we want to export. We might be able to hack around that with some grovelling around in the p-t branch before requesting an export, but it's probably better if we talk to the p-t maintainers first and implement a suitable mechanism for that in p-t itself. Then the gitpkg hook can just make use of that. Will look into this further. Cheers, Ron