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

Re: Some news from the website :)

Il giorno Sun, 14 Oct 2007 11:58:07 +0200 (CEST)
Andreas Tille <tillea@rki.de> ha scritto:

> On Sat, 13 Oct 2007, David Paleino wrote:
> > The severity-coloring has been implemented, please check it :)
> Great. Makes a really good overview.  From an estetical point of view
> I would choose some more decent colors like we have at
>     http://www.debian.org/devel/debian-med/microbio
> for instance - but that's polishing.

This has been fixed. :)

(those were "testing" colors though, I'm not that poorly tasted ;) )

> > I'll try to parse the task files then.

I've successfully implemented this, take a look :)

(still missing the APT information though -- I'll work on this next weekend

> Yesterday I tried to add the text:
> --------------------------------------------------------------------------------
> Depends: dialign-t
> Homepage: http://dialign-t.gobics.de/
> License: LGPL
> WNPP: 445983
> Pkg-Description: Segment-based multiple sequence alignment
>   DIALIGN-T is a command line tool to perform multiple alignment of protein or
>   DNA sequences. It is a complete reimplementation of the segment-base
> approach including several new improvements and heuristics that significantly
> enhance the quality of the output alignments compared to DIALIGN 2.2. For
> pairwise alignment, DIALIGN-T uses a fragment-chaining algorithm that favours
> chains of low-scoring local alignments over isolated high-scoring fragments.
> For multiple alignment, DIALIGN-T uses an improved greedy procedure that is
> less sensitive to spurious local sequence similarities.  DIALIGN-T has been
>   published in Amarendran R. Subramanian, Jan Weyer-Menkhoff, Michael
> Kaufmann, Burkhard Morgenstern: DIALIGN-T: An improved algorithm for
> segment-based multiple sequence alignment. BMC Bioinformatics 2005, 6:66.
>   .
>   DIALIGN-T is needed by dm_coffee, a special mode of t_coffee prepared
>   especially for Debian, in which non-free alignment software was replaced by
>   free alternatives.
> -------------------------------------------------------------------------------
> to tasks/bio.  This kind of works with the current cdd-dev tools but I
> regard this as a weak format for two reasons:
>     1. We need to write "Pkg-Description" because "Description" is also
>        the keyword for the meta-package description that will be moved
>        to the control file.  So we have to change the keyword for the
>        descriptions of prospective packages.
>     2. The task files syntax allows an arbitrary number of Dependand packages
>        after the keywords Depends/Recommends/Suggests.  To add a prospective
>        package we need to specify only one and have to make sure that all
>        information is matched to exactly this (future) package.

This kind of format is not a problem: I believe it's possible to implement it
in the same Python script. For clarity, I'd put these prospective packages in a
"wnpp" task file, possibly adding a "Task:" field to point to which task they
belong to. This will let me use separate methods for wnpp packages, instead of
using heuristics to determine if it's an available package or a wnpp one.

> I'm a little but undecided about this.  I'm kind of dreaming of switching
> the task file format to XML which would enable us a clear cut description.
> I'll discuss this with the Debian-Edu people I will meet next week in
> Merida.

Well, I'd have to change the Python script again :@

> So either we parse the meta packages dependencies to find out the
> relevant existing packages and grab the information of the not yet existing
> packages from the task files (which would IMHO mean more work) or we
> completely stick to the task files and leave the decision to other
> CDDs whether they like the comfort or refuse this extra stuff.

I believe that the task files should only mention available packages --
prospective ones should be put into a separate wnpp task.

> Kind regards
>           Andreas.


P.S.: the update-bugs script now takes a lot of time (about 10 minutes) to
complete (the increased number of packages...) -- SOAP isn't that fast (or
maybe it's SOAPpy's fault) -- but, hey, we're updating that twice a day, I
don't believe it would be a problem to Alioth.

 . ''`.  Debian maintainer | http://snipurl.com/qa_page/
 : :'  :  Linuxer #334216  |  http://www.hanskalabs.net/
 `. `'`    GPG: 1392B174   | http://www.debianizzati.org/
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174

Attachment: signature.asc
Description: PGP signature

Reply to: