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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
