[med-svn] [dazzdb] 01/01: Reformat long description to enable nice formatting in tasks pages

[Andreas Tille]

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 <tille at debian.org>
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 <debian-med-packaging at lists.alioth.debian.org>
 Uploaders: Afif Elghraoui <afif at ghraoui.name>
+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