Re: [MoM] Packaging mindthegap (Was: [MoM] Packaging mindthemap)
On Mon, Jul 08, 2019 at 10:47:17AM +0000, hello@shayandoust.me wrote:
>
> As for autopkgtest, there are too many documentations out there so I completely foresaw the need for that as I never invoked a test suite, which now I can see I'm wrong because I haven't seen how clearly it is mentioned in the debian med policy documentation.
I realised that your last commit contained a working autopkgtest.
Congratulations - that's quite a speady MoM project since I think
we are quite close to an upload now. There is one final thing:
E: mindthegap: python-script-but-no-python-dep usr/share/mindthegap/test/scripts/generate_read.py #!python
N:
N: Packages with Python scripts should depend on the package python. Those
N: with scripts that specify a specific version of Python must depend,
N: recommend or suggest on that version of Python (exactly).
N:
N: For example, if a script in the package uses #!/usr/bin/python, the
N: package needs a dependency on python. If a script uses
N: #!/usr/bin/python2.6, the package needs a dependency on python2.6. A
N: dependency on python (>= 2.6) is not correct, since later versions of
N: Python may not provide the /usr/bin/python2.6 binary.
N:
N: If you are using debhelper, adding ${python3:Depends} or
N: ${python:Depends} to the Depends field and ensuring dh_python2 or
N: dh_python3 are run during the build should take care of adding the
N: correct dependency.
N:
N: In some cases a weaker relationship, such as Suggests or Recommends,
N: will be more appropriate.
N:
N: Severity: important, Certainty: certain
N:
N: Check: scripts, Type: binary
N:
E: mindthegap: python-script-but-no-python-dep usr/share/mindthegap/test/scripts/make_deletions.py #!python
E: mindthegap: python-script-but-no-python-dep usr/share/mindthegap/test/scripts/make_snp_deletions.py #!python
E: mindthegap: python-script-but-no-python-dep ... use --no-tag-display-limit to see all (or pipe to a file/program)
So the test suite contains some Python scripts and thus the binary
package should reflect that dependency (most probably in a Recommends or
Suggests since the main binary does not really need Python). So far so
simple to silence lintian - but we actually need to do more.
First of all: Python2 is EOL and will not be released with Debian 11.
So I would do the following
cd test/scripts
2to3 --write --nobackups *.py
cd ../..
git diff > debian/patches/2to3.patch
git stash
echo 2to3.patch >> debian/patches/series
git add debian/patches/2to3.patch
quilt push -a
quilt refresh
quilt pop -a
$EDITOR debian/patches/2to3.patch # Add DEP3 header
git commit -a -m"Automatic port to Python3 via 2to3"
Since I just tested what I wrote here I thought simply commiting what I
wrote should safe you some time and thus I committed and pushed.
BTW, when checking your patches I noticed that you trapped into the
quilt-git-pitfall. Before doing some `git commit` you should call `quilt
pop -a` to unapply all quilt patches. This will ensure that all changes
to the upstream source will be reverted and the change is only inside
debian/patches. I fixed this in the Git repository.
Apropos quilt patches: There are some remaining
I: mindthegap source: quilt-patch-missing-description use_debian_packaged_gatb-core.patch
lintian infos. These belong to the set of "please always fix theses"
category since it helps your fellow developers. You now have an example
what fields you should provide. Hope this helps.
Now back to the python-script-but-no-python-dep issue. We have now
Python3 instead of Python2 scripts (the test suite also succeeds - I
have not checked whether the scripts are actually called - this should
probably be verified or call these manually to see whether the automatic
conversion was successfully).
We could now add something like
Recommends: ${python3:Depends}
to solve the lintian error above. However, I think we can avoid the
unneeded Python3 dependency and some unneeded payload for the binary
package if we would split the test data in
/usr/share/mindthegap/test
(may be the /usr/share/mindthegap/scripts/jenkins dir as well ?) into a
separate binary package "Architecture: all". This could be named
mindthegap-examples since users also could use the test script as
examples. Sometimes I use the name PACKAGE-data but in this case this
might be misleading since there are other data which most probably are
needed to run mindthegap and are not just optional. Since these data
are not large enough to provide them in a separate "Arch: all" package I
would leave it as is. But assumed these data might grow in future
versions we might need that *-data package for other things than just
test examples. Thus I would avoid the name *-data for the tests.
The creation of another binary package is another interesting item to
learn. We have lots of examples in the Debian Med team. Just sneak
into this. Its basically just another paragraph in debian/control
and moving some lines from debian/mindthegap.install to
debian/mindthegap-examples.install.
Apropos debian/mindthegap.install: Please leave out the LICENSE file.
Its just a copy of what you have in debian/copyright and lintian is
informing you about this.
Hope this all helps. If it opens more questions just feel free to
ask as usual.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: