On Thu, May 21, 2015 at 3:10 PM Andreas Tille <[email protected]> wrote:
> 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. :-) No worries! > 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 > Theoretically an end user might use some of these scripts to expand the program but most won't and those that do I would consider to be developers who can roll their own environment from source. Therefore I'd like to keep them out of the Debian package. > > > ... 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 > FYI: In my packaging I had the --setupdb command run during postinst. Regardless, since it compress decently we should figure out a way to run prokka --setupdb during package building so that its output is included in a prokka-data arch=all package. > > > > > 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. > Huzzah! > > > > 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. > Yep. > Perhaps in this case also the License field CC-BY-ND for these files is > not correct in this case. > Indeed, they need updating for our new understanding. > > Kind regards > Thanks as always!
