Hi Sébastien,
On Sun, Nov 04, 2012 at 10:46:23AM -0500, Sébastien Boisvert wrote:
> >The binary delta is between the original tarball and the collection of Git
> >objects corresponding to its content.
> >
>
> Oh I understand now.
> pristine-tar/x.y.z-R is something applied to upstream/x.y.z in order to
> produce package_x.y.z-R.orig.tar.bz2.
>
> Why not just pick the upstream tarball then ?
> Because you save on storage ?
Yes. Even if this might not really matter for ray it is just part of a
general workflow that is implemented in tools like git-buildpackage and
there are a lot of packages where it makes definitely sense. So
sticking to the very same workflow even if the gain in this specific
case might be not that remarkable makes sense.
> Thanks !
>
> I did
> pristine-tar commit ~/debian-med/ray_2.1.0.orig.tar.bz2
>
> I don't need to put any tag for branch pristine-tar, right ?
I tested the packaging using git-buildpackage and it worked for me - so
it seems you got the result right.
> too. This is equivalent to having "RayGit" and "RayPlatformGit" and then
> adding debian/.
I admit I do not understand this sentence - perhaps because the
difference between RayGit and RayPlatformGit is not clear to me.
However, the Debian Med team policy document[1] should explain
how to handle pristine-tar.
> >In that case, a pristine-tar binary
> >delta would contain a full copy of RayPlatform.
>
> But what's the workflow when upstream RayPlatformGit changes too ?
>
> Do we "pull" it inside branch upstream ?
>
> I guess I will use
>
> pristine-tar commit ~/debian-med/ray_x.y.z.orig.tar.bz2
>
> when we ship a new release ?
As I said above I do not really understand this. If you issue a new
source tarball (and I have no idea whether you do this for Ray and
RayPlatform in a synchronised manner) you create a new Debian package
from it. (No idea whether this answer might match the question.)
> >But given the size (856 here),
> >it may not be a problem if the number or releases is limited.
>
> So far, we ship around 3 to 6 releases per year. The bz2 tarball size is 330
> KB.
>
> So size is not an issue.
Definitely not in this case but as I said above sticking to a well known
workflow seems to have an additional and way more important advantage.
> > What you can
> >also do is generate an orig.tar.gz tarball from the Git repository on Alioth,
> >and then commit it in the pristine-tar branch.
> >
>
> I did this (see above). Thanks for the pointer.
Works as said above. :-)
Once having created the packages I would like to mention that I'm not
fully convinced that the split into ray-doc and ray-extra makes real
sense in this specific case. I'm usually a fan of separate binary
packages but in this specific case the sizes of both extra packages do
not rectify this extra effort at all. Stripping of some txt files
(ray-doc) and small scripts (in ray-extra) both ending up in binary
packages <50kB is something I would not do personally. In the end it is
a matter of taste but if you would decide to keep these packages they
should be "Architecture: all" in any case.
> >This said, there is no problem on Debian's side to package RayPlatform
> >separately.
>
> In RayPlatform, there is a CMakeList.txt and it can build
> libRayPlatform.so.
>
> The Makefile of ray needs a patch though:
>
> --- a/Makefile
> +++ b/Makefile
> @@ -185,16 +185,16 @@ showOptions:
> @touch showOptions
> # how to make Ray
> -Ray: showOptions RayPlatform/libRayPlatform.a code/TheRayGenomeAssembler.a
> - $(MPICXX) $(LDFLAGS) code/TheRayGenomeAssembler.a
> RayPlatform/libRayPlatform.a -o $@
> +Ray: showOptions RayPlatform/libRayPlatform.so code/TheRayGenomeAssembler.a
> + $(MPICXX) $(LDFLAGS) code/TheRayGenomeAssembler.a
> RayPlatform/libRayPlatform.so -o $@
> @echo $(PREFIX) > PREFIX
> @echo Ray > TARGETS
> code/TheRayGenomeAssembler.a:
> @cd code; make MPICXX="$(MPICXX)" CXXFLAGS="$(CXXFLAGS)" -j $(J) all
> ; cd ..
> -RayPlatform/libRayPlatform.a:
> - @cd RayPlatform; make MPICXX="$(MPICXX)" CXXFLAGS="$(CXXFLAGS)" -j
> $(J) ; cd ..
> +RayPlatform/libRayPlatform.so:
> + @cd RayPlatform; cmake .; make MPICXX="$(MPICXX)"
> CXXFLAGS="$(CXXFLAGS)" -j $(J) ; cd ..
> clean:
> @rm -f Ray showOptions PREFIX TARGETS
>
>
> $ ldd Ray
> linux-vdso.so.1 => (0x00007fff5a9ff000)
> libRayPlatform.so => /home/seb/git-clones/RayPlatform/libRayPlatform.so
> (0x00007f1be1752000)
> libmpi_cxx.so.1 => /usr/lib64/openmpi/lib/libmpi_cxx.so.1
> (0x00007f1be1538000)
> libmpi.so.1 => /usr/lib64/openmpi/lib/libmpi.so.1 (0x00000034d4e00000)
> libdl.so.2 => /lib64/libdl.so.2 (0x0000003d56000000)
> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003d5c400000)
> libm.so.6 => /lib64/libm.so.6 (0x0000003d55800000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003d58800000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003d55c00000)
> libc.so.6 => /lib64/libc.so.6 (0x0000003d55400000)
> libnsl.so.1 => /lib64/libnsl.so.1 (0x0000003d69c00000)
> libutil.so.1 => /lib64/libutil.so.1 (0x0000003d67000000)
> libltdl.so.7 => /lib64/libltdl.so.7 (0x0000003d66800000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003d54c00000)
>
> But at this point I think RayPlatform should be bundled because
> its API is not fully stable yet and as far as I know only Ray uses it.
>
> If a new package comes to Debian bundled also with RayPlatform,
> I will package RayPlatform and repackage ray. But we are not there yet
> I think.
I do not have time to dive into these technical details but I simply
trust your expertise here. As a rule of thumb you should be in favour
of modularising code into libraries *if* it makes sense. Your reasoning
to delay this to some point in future makes sense to me.
> >This is what I do with fastx-toolkit and libgtextutils.
>
> Is libgtextutils used by other packages as well ?
I can not answer this question but please be aware that the answer to it
is not always helpful to draw a final decision. My experience shows
that people are requesting libraries and even development packages for
those libraries even if they are not used at all by any package *inside*
Debian. There might be a lot of use for people developing applications
around this packaged software and they might profit from a library
package. I have no idea whether this is the case for libgtextutils nor
for RayPlatform.
Kind regards
Andreas.
[1] http://debian-med.alioth.debian.org/docs/policy.html
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121105081344.gb8...@an3as.eu
