Hi Faré,
On 2014-10-11 16:55 CEST, Faré fare@tunes.org wrote:
Looking at your patch https://github.com/darabi/asdf/commit/3e57db9e1e3488ed0269ea1d301fa29f0b83ed...
1- When you comment out (--git-upstream-tag="%(version)s"), which tree does it use as upstream? The current one? I suppose that will work.
It uses upstream/3.1.4. I renamed the upstream origin to point at my github fork.
2- What does --git-submodule do? Is it supposed to include the contents of ext/ in the tarball?
If you mean cl-asdf_3.1.4.orig.tar.gz, then yes, it includes the content of ext/ in the tarball.
How else could people apt-get source cl-asdf and be able to build the package themselves?
That's something we explicitly do NOT want in general — at least, we want to NOT include any of them in the .all.deb.
_all.deb is another story: it contains the subdirectories which are specified explicitly in debian/cl-asdf.dirs:
build/ uiop/ uiop/contrib/ contrib/ tools/
Is the issue that otherwise robots can't build the package because the asdf-tools are used at build time and then we need to package each of the dependencies in its own .deb? But I believe we are NOT using the asdf-tools at package build time, only while extracting the package from source.
IIUC, asdf-tools are needed for the build process itself, so they should be part of the source package such that a debian user who would like to build the package him/herself would be able to do so.
And because the .gitmodules information is lost during debian packaging, it is necessary to have the code of the ext/ submodules in the .orig.tar.gz. Otherwise nobody could build the package without hunting the dependencies.
Or do I misunderstand something?
Kambiz