Re: Packaging Ray for Debian Med
Hi !
On 11/05/2012 03:13 AM, Andreas Tille wrote:
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.
I thank you for showing me how to do it.
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.
I want the ray-extra because ray contains the executable Ray whereas
ray-extra has some R and python scripts which are not used in most Ray
workflows. Thus, I don't want the ray package to require (or suggest)
r-base-core or python.
ray-doc contains documentation not required to operate Ray.
The man page alone is sufficient.
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.
Fixed.
http://anonscm.debian.org/gitweb/?p=debian-med/ray.git;a=commitdiff;h=446f11f7b4522f7c4664e5ac8eb0e4c9d87f55a3
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
--
Sent from my IBM Blue Gene/Q
Reply to: