[pkg][dhcpig] ready for review

phil at reseau-libre.net phil at reseau-libre.net
Fri Jun 23 07:49:16 UTC 2017


On 2017-06-22 17:30, Raphael Hertzog wrote:
> Hello Phil,

Hello Raphaël,

> 
> On Mon, 19 Jun 2017, phil at reseau-libre.net wrote:
> 
> This is not the correct version to use. First of "0:" is exactly the 
> same
> as no epoch at all. Then when you don't have any upstream version, you
> should certainly not assume that 1.0 is acceptable. You should aim for 
> the
> lowest possible version for example 0~git20170428-1. Then you will be 
> fine
> even if upstream releases the next version as 0.0.1 (~ is lower than
> anything else).

Thank you for this complete explanation on how to manage untagged 
upstream. I've seen various ways to handle them, nearly all different 
:-/
I've updated as you explained.

> 
> Other comments:
> - please submit your patches upstream, both help.patch and
>   pybuild_mode.patch are "upstreamable"

Done :)

> - "XS-Python-Version: >= 2.7" in debian/control is sort of useless,
>   we have a single python 2 version currently and for the future...

Updated also. I've replaced '>= 2.7' with 'all', if it is what you 
imagined.

> - you don't need to hardcode the "python" dependency in the Depends
>   of dhcpig, it's generated as part of ${python:Depends}.

Corrected.

> - please use "https" for the Format line in debian/copyright

Corrected.

> - please rename debian/docs into debian/dhcpig.docs and debian/manpages
>   into debian/dhcpig.manpages, the idea is to cleanly separate files
>   that apply to binary packages from files that apply to the source
>   package as a whole

I have to take this habit... :) Done.

> - I see that you always bother to create an upstream changelog with 
> some
>   custom rules in debian/rules and a quilt patch, it's nice but you 
> don't
>   have to do that... it's fine if there is no upstream changelog in the
>   package.

Ok i thought it was better to have one. I cleaned the content.
When there is a real upstream changelog in github (made with the 
releases) - not the case of dhcpig - i also made a little script to get 
back the changelog from github. In this case i imagine that i can keep 
the script to get it back ?

> - in debian/rules I see you pass "-O--buildsystem=pybuild" to
>   dh_auto_build and dh_install... it should not be needed. The "dh $@
>   --with python2 --buildsystem=pybuild" call is already setting 
> everything
>   required so that all dh_* commands know which buildsystem is in use
>   (IIRC it uses some environment variables to do this)

Updated. I wasn't sure if the override keep the environment. I've seen 
this way to write the rules file in various packages so i thought it was 
a "classical" way.

> - can you explain the following two lines?
> # redirect module to correct dist-packages dir
> export 
> PYBUILD_INSTALL_ARGS=--install-lib=/usr/lib/python2.7/dist-packages

I didn't remember well why, but when i started the packaging of another 
python pkg, the installation was not made in this directory but in 
another one (i thought it was for a python3 package, and the install was 
in /usr/lib/python3.5/dist-packages instead of 
/usr/lib/python3/dist-packages, making lintian complain.
In that case i have no errors without that line.

> - note that help.patch contains an unrelated change (adding parenthesis 
> to a
>   print call, it's nice for Python 3 compat but doesn't change anything
>   otherwise)

Yes it was mostly psychologic from my part :)... some old perl 
programming stresss :) I've cleaned it.

I've also updated standards-version to 4.0.0.

> 
> Cheers,

Cheers,
-- 
Philippe.



More information about the Pkg-security-team mailing list