Packaging EMBOSS and data for EMBOSS
Le Thu, Apr 26, 2007 at 04:32:35PM -0400, Aaron M. Ucko a écrit :
>
> - Although the command I used (debuild -B) was supposed to build only
> the architecture-dependent (arch-amd64) packages, it built
> architecture-independent (arch-all) packages as well;
>
> - Three executables in emboss (and their manpages, once they
> materialize) implicitly conflict with other packages in the
> archive, in violation of Policy 6.6(4):
>
> - The shared libraries in emboss-lib contain a number of unresolved
> references to symbols from other libraries, in violation of Policy
> 10.2; please take care to link them against the libraries they
> need.
>
> - The binaries contain extraneous rpath entries for /usr/lib,
> presumably due to using a buggy version of libtool.
>
> Could you please address these issues prior to letting emboss into
> unstable?
Dear Aaron,
many thanks for the upload. Indeed, the reason why we used experimental
is that we suspected that EMBOSS is not yet suitable for unstable from a
QA point of view. The problems with the libraries are a bit hard for me,
so do not hesitate to give a few more hints if you have more time.
By the way, I would like to take the opportunity to ask you and the list
your opinion about the mirbase package that I prepare.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420938
http://svn.debian.org/wsvn/pkg-emboss/mirbase/trunk/debian/?rev=0&sc=0
For the moment, the package (in construction and currently broken):
- Indexes an EMBL-formatted miRNA database for EMBOSS, ships it in
/usr/share/mirbase/emboss (should the database itself be
/usr/share/mirbase/embl ?), and drops a small embossrc file in
/etc/emboss/embossrc.d
- converts it to FASTA format using EMBOSS, and ships it in
/usr/share/mirbase (/usr/share/mirbase/fasta ?)
- Indexes it for NCBI-Blast with formatdb, and ships it in
/usr/share/mirbase/blast
- will later insall the mirbase as a mySQL database.
Do you think that the layout makes sense? EMBOSS can tap in databases in
various directories, and I was thinking that users can make symlinks
from /usr/share/mirbase/blast/mir* to the directory to which BLASTDB
points...
Also, mirbase is quite small, and I am wondering when it would make
sense to split that kind of package between mirbase-blast, mirbase-fasta
and mirbase-embl for instance.
I think that with a size of ~ 3 Mo it is intersting to provide mirbase
from within Debian, but definitely this scheme is not valid for bigger
sizes. The human genome is definitely to be packaged as a wrapper, but
where to put the cutoff?
Lastly, as all of this takes some space, I also wonder if it is
acceptable by policy to have the heavy data under something like
/usr/share/bioinformatics, in order to let sysadmins dedicate a
partition to this.
Have a nice day,
--
Charles Plessy
Wako, Saitama, Japan
Reply to: