[pkg] backdoor-factory ready for review

[Raphael Hertzog]

On Fri, 23 Jun 2017, phil at reseau-libre.net wrote:
> I've updated the packaging model by defining a "bdfactory" package. The
> various modules are installed as modules of the bdfactory package so that
> everything is in this directory in the dist-packages directory. This require
> some patch in the .py files on the import line but this permit to install
> properly in the dist-packages dir instead of /usr/share.
> I've tested the tool in a sid chroot, it works properly with the new
> install. I've executed the debian-ci scripts to check.
> 
> Before posting an issue (and a merge request with the patch), i would like
> to have your point of view on this. If you think it is ok, i will create the
> issue & merge request on upstream and add the Bug: line in the patch header.

For me it looks good. You can submit this upstream and see whether it
gets accepted.

But I would not upload a Debian package relying on this until it gets accepted
upstream.

> > - rename debian/docs into debian/backdoor-factory.docs and drop
> > "debian/*"
> >   from that file... README.Debian is automatically installed,
> >   README.source is meant for packagers only and should not be installed
> >   in binary packages.
> 
> done. I'm asking myself if this file is still usefull as, if i remember
> well, the README.md file is automatically added by dh_installdocs. This file
> is the last content.

man dh_installdocs doesn't say anything about README.md being installed by
default.

> Updated (cleaned helper script to install the script directly in /usr/bin. I
> didn't find a way to name the script properly (without the .py extention) so
> there is a line in the rules file to rename it. I don't know which is the
> better way beetween installing the utility directly in /usr/bin or using a
> helper script yet i don't see the advantage of using such an indirection (in
> the case of dist installed package).

Sometimes the helper script helps to change the current directory to the
directory expected by the upstream script... they are often designed to
work only out of the checkout and don't work very well when installed in
/usr/bin.

But if there are no such problems, then it's ok to install the script
directly in /usr/bin.

> >   At the same time, outputting a message about Debian not allowing
> >   something looks wrong. We might be missing "appack" but the user might
> >   have installed it in some other way. You can fail gracefully if you
> >   don't have it without claiming that Debian doesn't support it.
> 
> Ok I've updated so that if the appack bin exists, the code is executed,
> otherwhise, a message only print that appack is not found.
> The indent update make the patch bigger but there is less lines really
> modified.
> The output dir part of the patch (other that Debian related due to appack
> check) has been pushed as an issue in the upstream and the patch file
> reference it.

The appack part can certainly be submitted upstream too. 

But this part looks strange:
+                if subprocess.call("type appack", shell=True,
+                                   stdout=subprocess.PIPE,
+                                   stderr=subprocess.PIPE) == 0:

Why are you redirecting to a PIPE if you are not reading the data
from the pipes? Shouldn't you use /dev/null in some way?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/