Re: Bug#909716: Request for sponsoring changes in idba
Hi Pranav,
On Fri, Mar 13, 2020 at 10:21:34PM +0530, Pranav Ballaney wrote:
> > In my commit 6cff0c2377861eb179d4ec06514df75df1323510 I tried to fix this
> > but did not test which I'll leave you for an exercise. ;-)
>
> Thanks, this worked, but initially it didn't compile. The error was that it
> couldn't find any *.1 files in debian/idba and debian/idba-extra.
> However, when I renamed the two folders to idba-man and idba-extra-man, it
> suddenly worked. Do you have any ideas why this was so?
Sure. It was my fault to forget the '-man' (you see even I'm doing
beginners errors ;-) ). Debhelper installs into debian/tmp for single
binary packages. However, multi binary packages are installed into
debian/PKGNAME
for each PKGNAME. If these directories exist they are removed (or
something else unwanted is happening.
> > When doing so I stumbled upon the script run-unittest.py which I think
> > should not end up in /usr/bin. I installed it into docs and your second
> > exercise could be to check whether it really does some sensible testing
> > at all. As far as I can see it is just triggering the build time test
> > but it does not look as if it be useful to install on users machines.
> > Even if it would make sense the name /usr/bin/run-unittest.py is way to
> > generic and should be avoided. Same with /usr/bin/scan.py - please
> > check whether this script makes sense in /usr/bin it should be probably
> > renamed (to something like idba_scan.py). Otherwise it should also go
> > to /usr/share/doc/idba (or left out fully).
>
> Yes, it should definitely not go to debian/bin, sorry.
No need to sorry.
> Line 17 in debian/rules [1] says, "for the moment the role of these scripts
> is totally unknown but they do not seem to be necessary," and proceeds to
> copy run-unittest.py, scan.py, validate_blat and validate_blat_parallel to
> usr/lib/idba.
> I tried commenting out these lines, and the package seems to work just
> fine. They seem to be required only during compilation and testing, so they
> probably shouldn't be installed as binaries in the final user installation.
> Maybe we could let them be in the lib folder?
>From my perspective these scripts are perfectly hidden in lib. I think
run-unittest.py is a good candidate for the docs - may be accompanying our
test script.
> I'm not sure, however. Please take a look and let me know if I should
> change it to docs.
Regarding scan.py the header says:
Scan src directory recursively to build Makefile.am automatically.
I do not think that's useful inside the package. For the moment I
did not installed these files.
> > That's really good! The only think I'm missing now is that we should
> > always mention the origin where the data were obtained from (may be in
> > a script calling wget for downloading). It makes also sense to drop
> > some note about the license of these files.
>
> I have added a file called data-source.sh in debian/tests/test-data. Is
> this the right way to do it?
Yes, that's perfect.
> Also, I obtained the data from their research papers about these tools.
> What kind of license would be applicable in this case?
If there is no explicite license statement we can probably leave it as
is since we have documented the location where to obtain the data and
possibly ask the authors in case of questions.
> And where do I get the license from?
An case of doubt try to contact the authors. But in this case I'd I
personally would not undergo any extra effort.
> > I'd perfectly accept some kind of "lazyness" here. I would not mind
> > uploading the current incomplete status despite of the lintian warnings.
> > I usually decide according to the "importance" of the tool that needs a
> > manpage. My motivation was to get "the first three in list" and also
> > the ones we are using in autopkgtest. Feel free to decide whether you
> > want a complete set of manpages or not.
>
> Okay. I think the set of manpages we have should be enough, given that the
> other tools aren't too important.
Fine for me.
> Thanks for the intro to dh_install, man pages and documentation about
> packages.
I consider this part of my mentoring job. Its also now in the web archive
of the mailing list to help other newcomers.
> Please let me know if any more work is required on this package.
I cleaned up the changelog a bit since for the external reader the
details in the development of this very upload is not very informative.
Thanks a lot for your work on this
Andreas.
--
http://fam-tille.de
Reply to: