Bug#681685: RFS: homealoned/0.4.1-1
On Tue, Sep 18, 2012 at 3:44 PM, Helmut Grohne <helmut@subdivi.de> wrote:
> 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.
Thank you for your interest
> 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.
You are right.
I can do that :)
> 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.
Again you are right. Its only documented on the .conf file but i
somehow managed to skip that in the man page. It only works in any /24
you configure as is the most common one, for now :)
> 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.
no reason im aware of. I can change that.
> 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?
dget -x http://mentors.debian.net/debian/pool/main/h/homealoned/homealoned_0.4.1-3.dsc
There is a newer version with some small fixes, including description.
This is the latest version available of the software packaged.
You probably did not see it because i keep track of them in the
mentors page, and I did not update the bug report
https://mentors.debian.net/package/homealoned
> 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.
Again you are right... i can remove the useless comments like "add
here commands".
I chose the old style because im learning and i like to know what is
doing. At some point, i intend to adopt the new cleaner style :)
> 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)
Yup, I was aware of this one. There is a number of small fixes like
this one that are planned for the next release
> 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.
The network is not very difficult to add and is planned as well. I
first scratched my itch and now im turning it into a more general use
case program.
About the second part, maybe im not doing it right... i gave a little
thought about this problem and in my experience:
a) it does not matter how tight you set the transfer rates... it
always had an impact in latency for me when running stuff like
torrent. This might not be noticeable for web browsing, but it is
important for gaming. I always had to shutdown servers when gaming.
b) this is intended to run on a server like a plugserver and take care
of the rest of the network. You cant run a packet scheduler if your
computer is not the only one on the network.
c) to set up qos you have to be in control of the gateway... witch you
might or might not be. In my case, even in some places where i could
put myself in the middle of everything, i just dont want to pick up
the responsibility of becoming the gateway. Aka... if my little server
blows up, nobody else can connect to the internet because of "my"
machine and i get a call. :). Also, qos seems over killing for a small
lan.
d) it might be easier to run some snmp analysis against the gw or
become the dhcpd... again... i want to avoid that for the same reason
as c)
This way allows me to forget completely im running the services. Its
being working beautifully for 4 months now without touching it once :)
> 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.
Yup. I have a little TODO list full of more or less easy little tasks to do.
Thank you again for the thoughtful response. I will be uploading a new
version soon since i have little more time now :)
> Helmut
Reply to: