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

Re: Fwd: Prokka Debian package?



Hi Michael,

On Thu, May 21, 2015 at 06:14:48PM +0000, Michael Crusoe wrote:
> > http://anonscm.debian.org/cgit/debian-med/prokka.git/commit/?id=91b39ca656f979b3c2c704d8756d9e04e54ae5f9
> > >
> > > `prokka-tigrfams_to_hmm` & `prokka-make_tarball` are not for end users
> > > which is why I didn't ship them.
> >
> > ?  The code and the description do not match.  According to the code you
> > ship all files in bin/*, right?
> 
> I believe your commit switched to shipping all files in bin/*. I had the
> preselected list prior.

Cool, changing something and blaming somebody else about it. ;-)

I think I suspected "new" binaries and considered it simpler to use "*"
which would cover all new things.  That's the result if somebody pokes
around without deeper knowledge.

I reverted my change to your version - sorry for this.  However, if you
say it is not for end users is it possibly for root (my colleague told
me that root needed to call a db generation script).  If this would be
the case I'd consider:

$ git diff
diff --git a/debian/prokka.install b/debian/prokka.install
index c06d46a..0aa4238 100644
--- a/debian/prokka.install
+++ b/debian/prokka.install
@@ -7,3 +7,6 @@ bin/prokka-genbank_to_fasta_db  usr/bin
 bin/prokka-genpept_to_fasta_db usr/bin
 bin/prokka-hamap_to_hmm                usr/bin
 bin/prokka-uniprot_to_fasta_db usr/bin
+bin/prokka-build_kingdom_dbs   usr/sbin
+bin/prokka-make_tarball        usr/sbin
+bin/prokka-tigrfams_to_hmm     usr/sbin


... assuming that the new prokka-build_kingdom_dbs is also of this
nature.  If it is for end users it probably needs to be added to the
usual set of installed files.

> > BTW, without diving into the code and checking myself I can just quote a
> > colleague of mine who installed prokka manually that you need to
> > generate something as root (prokka --setupdb).  I have mixed feelings
> > about this why this needs to be done by root and whether the resulting
> > files should not rather go to /var/lib/prokka.  We should not bloat /usr
> > by files out of control of dpkg.
> >
> 
> It generates 2.1GiB of files and one only needs to be root to write them in
> the correct place. With the extra files the upstream tarball compress down
> to 270MiB using XZ and its default compression level (-6)
> 
> Is that too large to ship as an arch=all data package?

We should probably fill the debian mirrors with good reasons but I have
not heard that there is some upper limit for package space.  There is a
several years existing plan about a data area which for instance is not
mirrored to so many mirrors world wide.  Since this has not been
realised we might simply increase the pressure to realise the plan by
starting to upload such packages.  May be some mirror admin will start
implementing things and provide code to ftpmaster?

But to be clear about this root-issue:  We know that root can write
files where ever needed.  However, root *should* *not* write manually to
/usr.  Locations like /var, may be /usr/local or /srv are fine but /usr
should be clean from files that are not

   a) inside the package and
   b) created in {pre,post}inst and deleted in {pre,post}rm
 

> > Seems you are refering to README.Debian
> >
> >   Prokka's databases are installed to /usr/share/prokka
> >
> >   HAMAP.hmm is 224M, took 21 hours and 10 minutes, 15M of memory, single
> > threaded?
> >
> >   Shipped HAMAP.hmm is 88M ??
> >
> > right?  Am I understand you correctly that the base data are free and
> > just the processing of 21hours should be CC-BY-ND?  I can not believe
> > this since this would be insane.  Sorry for my naïve question.
> >
> 
> The original databases (not shipped by upstream) are CC-BY-ND. It is now my
> understanding that the derived files (using the uncopyrightable facts from
> the CC-BY-ND databases but not their structure or organization) are not
> subject to the CC-BY-ND license.
> 
> So I think we are okay to distribute after all.

Sounds logical to me.
 
> > Definitely.  However, I'm not sure whether my personal opinion is
> > helpful here.  I remember I was sending a series of e-mails to authors
> > of databases shipped with emboss and in the end we were able to clear
> > out all licenses.  No idea in how far this will lead here.  In any case
> > I'm sure that ftpmaster will refuse a package that contains some
> > CC-BY-ND data (and will probably not dive into a discussion whether
> > facts of nature are copyrightable or not).
> 
> Hmm.. There is no data copied from any CC-BY-ND databases. The
> uncopyrightable facts that were retrieved from those databases were
> transformed into a new work (the HMMs).

This should be made pretty clear in a Comment field in debian/copyright.
Perhaps in this case also the License field CC-BY-ND for these files is
not correct in this case.

Kind regards

        Andreas.

-- 
http://fam-tille.de


Reply to: