Re: Packaging Ray for Debian Med
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
Reply to: