This is an automated email from the git hooks/post-receive script. tille pushed a commit to branch master in repository dazzdb.
commit df2fec8b8bd6db58cad5f4b4aad884f07496d32f Author: Andreas Tille <[email protected]> Date: Mon Sep 14 08:24:16 2015 +0200 Reformat long description to enable nice formatting in tasks pages --- debian/control | 64 +++++++++++++++++++++++++++++++--------------------------- 1 file changed, 34 insertions(+), 30 deletions(-) diff --git a/debian/control b/debian/control index bb6a615..5b2deb2 100644 --- a/debian/control +++ b/debian/control @@ -1,41 +1,45 @@ Source: dazzdb -Section: science -Priority: optional Maintainer: Debian Med Packaging Team <[email protected]> Uploaders: Afif Elghraoui <[email protected]> +Section: science +Priority: optional Build-Depends: debhelper (>= 9) Standards-Version: 3.9.6 -Homepage: https://github.com/thegenemyers/DAZZ_DB -Vcs-Git: git://anonscm.debian.org/git/debian-med/dazzdb.git Vcs-Browser: http://anonscm.debian.org/cgit/debian-med/dazzdb.git +Vcs-Git: git://anonscm.debian.org/debian-med/dazzdb.git +Homepage: https://github.com/thegenemyers/DAZZ_DB Package: dazzdb Architecture: any Depends: ${shlibs:Depends}, - ${misc:Depends} + ${misc:Depends} Description: manage nucleotide sequencing read data - To facilitate the multiple phases of the dazzler assembler, we organize all - the read data into what is effectively a database of the reads and their - meta-information. The design goals for this data base are as follows: - * The database stores the source Pacbio read information in such a way that - it can re-create the original input data, thus permitting a user to remove the - (effectively redundant) source files. This avoids duplicating the same data, - once in the source file and once in the database. - * The data base can be built up incrementally, that is new sequence data can - be added to the data base over time. - * The data base flexibly allows one to store any meta-data desired for reads. - This is accomplished with the concept of *tracks* that implementors can add as - they need them. - * The data is held in a compressed form equivalent to the .dexta and .dexqv - files of the data extraction module. Both the .fasta and .quiva information - for each read is held in the data base and can be recreated from it. - The .quiva information can be added separately and later on if desired. - * To facilitate job parallel, cluster operation of the phases of our - assembler, the database has a concept of a *current partitioning* in which - all the reads that are over a given length and optionally unique to a well, - are divided up into *blocks* containing roughly a given number of bases, - except possibly the last block which may have a short count. Often programs - con be run on blocks or pairs of blocks and each such job is reasonably well - balanced as the blocks are all the same size. One must be careful about - changing the partition during an assembly as doing so can void the structural - validity of any interim block-based results. + To facilitate the multiple phases of the dazzler assembler, we + organize all the read data into what is effectively a database of the + reads and their meta-information. The design goals for this data base + are as follows: + * The database stores the source Pacbio read information in such a + way that it can re-create the original input data, thus permitting + a user to remove the (effectively redundant) source files. This + avoids duplicating the same data, once in the source file and once + in the database. + * The data base can be built up incrementally, that is new sequence + data can be added to the data base over time. + * The data base flexibly allows one to store any meta-data desired for + reads. This is accomplished with the concept of *tracks* that + implementors can add as they need them. + * The data is held in a compressed form equivalent to the .dexta and + .dexqv files of the data extraction module. Both the .fasta and + .quiva information for each read is held in the data base and can be + recreated from it. The .quiva information can be added separately and + later on if desired. + * To facilitate job parallel, cluster operation of the phases of our + assembler, the database has a concept of a *current partitioning* in + which all the reads that are over a given length and optionally + unique to a well, are divided up into *blocks* containing roughly a + given number of bases, except possibly the last block which may have + a short count. Often programs can be run on blocks or pairs of blocks + and each such job is reasonably well balanced as the blocks are all + the same size. One must be careful about changing the partition + during an assembly as doing so can void the structural validity of + any interim block-based results. -- Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/debian-med/dazzdb.git _______________________________________________ debian-med-commit mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-commit
