Bug#681685: RFS: homealoned/0.4.1-1
On Sun, Jul 15, 2012 at 05:42:12PM +0200, alberto fuentes wrote:
> dget -x http://mentors.debian.net/debian/pool/main/h/homealoned/homealoned_0.4.1-1.dsc
Nobody seems to care for this package at all. What a shame. Now I had a
look.
First and foremost, the upstream source hides the licensing information
very much. There is no license file, no mentioning in a README, no
license header in the perl script. Deep down in the show_version sub
there is a small "GPLv3+" once you know what you are looking for. I
believe that this is not enough to make the source redistributable by
Debian. Please extend the licensing information upstream.
The package is set up to serve a 192.168.1.0/24 network. There is no
mentioning in the documentation that this is the case, nor is there an
explanation on how to change it. In fact the software only works with
/24 networks.
Now let me come to a packaging point of view.
Is there a specific reason to build-depend on debhelper >= 8.0.0 instead
of just 8? As far as I know just the first number is fine for debhelper
and when you switch to 9, there will only be a date anyway.
The description of the package could be improved in terms of language.
There are a number of small issues like grammar (e.g. "Daemon that
run[s]") or spelling mistakes (e.g. "ne[t]work"), nothing standing out.
Maybe you can ask debian-l10n-english@lists.debian.org for help here?
Your debian/rules file contains a huge amount of cruft. Comments such as
"Sample debian/rules that uses debhelper." or "Add here commands to
compile the package." are simply wrong in this context. You can use dh
to significantly shorten this file, but you don't have to. Invoking all
dh_ commands individually is fine, it just becomes less common nowadays.
The daemon seems to create a log file /var/log/homealoned.log which does
not seem to be rotated. This is a policy violation. (Section 10.8)
That said, I believe that the package is not being a good fit for the
Debian project due to its limited applicability (/24 networks only),
lack of documentation (change network from 192.168.1.x), but also
because it is serving a very specific use case. For instance instead of
starting tor via homealoned it might be sufficient to use a very rigid
packet scheduler and run tor all the time.
This is not to say that the package cannot evolve. Most of the points I
mentioned should be easily solvable. My point of view merely applies to
the package in its current shape. In addition the package does not seem
to duplicate the functionality of another existing package, which is
generally a good sign.
Helmut
Reply to: