On Thu, Apr 7, 2016 at 1:02 PM, 立花一樹 wrote: > 1. This source includes python script code which is named "crpp". > But this code is implemented in python2. > It goes against Debian policy.
Python 2 is fine at this point in time. It would be nice if upstream could support Python 3 as well since we are moving towards using that. > 2. The default installation path of "crpp" is located to /usr/libexec which > is specified "pkglibexec_SCRIPTS" tag > in Makefile.am . But It goes against policy of FHS. > So, I hesitate where to install this script. The default debhelper configuration code contains this, I would say you can just use the defaults: if (! compat(8)) { if (defined $multiarch) { push @opts, "--libdir=\${prefix}/lib/$multiarch"; push @opts, "--libexecdir=\${prefix}/lib/$multiarch"; } else { push @opts, "--libexecdir=\${prefix}/lib"; } } else { push @opts, "--libexecdir=\${prefix}/lib/" . sourcepackage(); } > 3. This "crpp" code needs "oui.db" during execution which is similar to " > oui.txt" in ieee-data package. > So, I have some concern about duplication between "oui.db" and "oui.txt" > if we'll install them directly. If you can get upstream to add support to crpp for reading oui.txt directly instead (should be a few lines of code), that would be the best way to do deal with this and you can just depend on ieee-data. If they won't do this, then you can create oui.db from oui.txt in ieee-data at build time and set Built-Using so that the binary package declares which version of ieee-data it was built from. > So, I decided to omit "crpp" and "oui.db" from my package in this time. > But I dither over how to go forward my packaging process in this case. > Would you give me some advice ? Looks like lsfirewire uses the crpp script if it is present, so I think it would be best to keep it if possible. -- bye, pabs https://wiki.debian.org/PaulWise