Hi Sébastien, many thanks for your work and for your interest into Debian Med.
On Fri, Nov 02, 2012 at 12:08:23AM -0400, Sébastien Boisvert wrote: > [I posted this already, but before confirming my subscription] (Remark: you do not necessarily need to subscribe the list to be able to post - but if you are interested in this field I hope you will profit from the discussion here.) > > I successfully created a Debian package for Ray 2.1.0. > > You will find packages here in a git repository: > > https://github.com/sebhtml/ray-debian-package This looks good for a first attempt but needs some further polishing. The Debian package policy checker lintian claims some issues that need fixing before we can upload the package to the official Debian mirrors. > I installed my .deb with dpkg -i, tested it with some data, > checked what's in it with dpkg -L ray|less, and finally removed it > from my virtual machines (i386 and amd64). > > I will add a sparc package tomorrow. I have no idea in how far you personally will need a sparc package. Regarding Debian there is no real need to manually build packages for different architectures because so called autobuilders grab uploaded packages from one architecture and build all other official Debian architectures. > Can you review what I did ? See my more detailed remarks below - I'll add some comments to Tim's posting as well. > On 11/01/2012 08:10 AM, Tim Booth wrote: > >Then you could start by reading this documentation: > > > >http://developer.ubuntu.com/packaging/html/packaging-new-software.html I havn't read this but I would also consider the Debian Med team policy[1] a nice reading for your purpose. It links to some other introductionary documentation and also describes some rules we are using here in the team. If you are mainly targeting at Ubuntu please be not disturbed that the document is quite Debian centric. The basic idea is that those packages that are properly integrated into Debian will easily move to Ubuntu. We intend to feed the source (Debian is upstream for Ubuntu) properly here in the Debian Med team which makes Tim's job for deriving BioLinux from Ubuntu hopefully as simple and straightforeward as possible. > >>>you were interested in making Ray into a .deb package that could be > >>>hosted on Launchpad.net? This is slightly more effort in the first > >>>place but has several benefits: > >>> > >>> * The .deb package will be usable by every user of Debian, Ubuntu > >>> and derivatives > >>> * The .deb package could, in future, be submitted to the main > >>> Debian archive via Debian-Med so it would start appearing in the > >>> Software Centre etc. > >>> * CloudBioLinux will be able to add Ray without the patch to > >>> bio-nextgen.py, and will also see updates automatically rather > >>> than being hard-coded to 2.1.0 > >>> * The Launchpad auto-build system will build binaries for multiple > >>> architectures, run unit tests, and check for build issues after > >>> any dependency updates Considering that you are writing to the Debian Med mailing list I assume you might not only target at a LaunchPad PPA but rather at an official Debian package which as I mentioned above would have additional advantages to the ones mentioned above by Tim (for instance autobuilders as I mentioned above). Please correct me if my assumption is wrong and if you wonder about those advantages. Now to your actual work at https://github.com/sebhtml/ray-debian-package I cloned this and before I will go into the technical packaging details I would like to suggest to consider maintaining the packaging in the Debian Med team repository at alioth.debian.org as described in Debian Med team policy[1]. The suggested repository layout (using pristine-tar for injecting the upstream source) is quite helpfull if you want to use nifty tools like git-buildpackage and others. I'm personally no Git expert but there are people reading this list who can give you advise how to maintain clones at alioth.debian.org as well as on github.com if you like to stick to github for whatever reason. I guess if you might consider your time better spend by sticking to your current workflow and do not want to subscribe at alioth.debian.org somebody from our team can perfectly take over it here. The great advantage would be that anybody from the team (also Tim) can immediately fix things in your packaging which probably could speed up the finishing of the package. Now to your actual packaging. I have build it as well and while I can confirm that some working package is builded there are several issues found by the policy checker lintian: $ lintian ray_2.1.0-1_amd64.changes E: ray source: depends-on-build-essential-package-without-using-version make [build-depends: make] E: ray source: build-depends-on-build-essential build-depends W: ray source: ancient-standards-version 3.8.4 (current is 3.9.3) W: ray: hardening-no-relro usr/bin/Ray W: ray: hardening-no-fortify-functions usr/bin/Ray W: ray: new-package-should-close-itp-bug E: ray: helper-templates-in-copyright E: ray: description-starts-with-package-name W: ray: description-starts-with-leading-spaces W: ray: package-contains-upstream-install-documentation usr/share/doc/ray/INSTALL.txt W: ray: extra-license-file usr/share/doc/ray/LICENSE.txt W: ray: binary-without-manpage usr/bin/Ray E: ray: python-script-but-no-python-dep usr/share/ray/scripts/NCBI-Taxonomy/Create-Taxon-Names.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/NCBI-Taxonomy/GenerateTaxonNames.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/NCBI-Taxonomy/getName.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/NCBI-Taxonomy/getNameInFile.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/getSeq.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/illumina-split-linked-sequences-fastq.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/interleave-fasta.py E: ray: python-script-but-no-python-dep usr/share/ray/scripts/interleave-fastq.py W: ray: unusual-interpreter usr/share/ray/scripts/plot-color-distributions.R #!/usr/bin/Rscript W: ray: unusual-interpreter usr/share/ray/scripts/plot-coverage-distribution.R #!/usr/bin/Rscript W: ray: unusual-interpreter usr/share/ray/scripts/plot-library-distribution.R #!/usr/bin/Rscript If you call lintian with option '-i' you get some more detailed information about what might be the actual problem and how to fix it in your packaging. I could easily go into more detail if something remains unclear to you but it seemed easier to me to agree to a common workflow first. So please just tell me what you think and we will try to fix this together after agreeing to a wrokflow that fit our needs best. Kind regards and thanks for your interest in Debian Med Andreas. [1] http://debian-med.alioth.debian.org/docs/policy.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121102091213.gb4...@an3as.eu
