[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


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
 - 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
 - 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

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: