Hi On Mittwoch, 19. März 2008, Sven Mueller wrote: > Stefan Lippers-Hollmann wrote on 18/03/2008 17:49: > > Agreed, the current use of local in lirc's initscript is neither covered by > > SUSv3, the exceptions from SUSv3 described in Debian policy 10.4, nor > > actually providing any vital functionality in said initscript, therefore it > > has been fixed in svn: > > > > http://lists.alioth.debian.org/pipermail/pkg-lirc-changes/2008-March/000392.html > > I looked at your patch, and to be honest, I would have solved this issue > by replacing > local a=foo > with > local a > a=foo
That would have been the simpler approach to meet Policy 10.4 by making use
of the explicit exceptions to SUSv3, but honestly I saw no pressing reason
to use non-SUSv3 features there at all. Actually unset -v is imho already
over-engineered, given that there are no namespace collisions and the
initscript itself being short and simple enough for just freeing the memory
on exit, but felt that keeping the behaviour close to identical would have
been preferred.
> instead of just removing the local declaration. Any problem with me
> reverting your patch and doing as described above? I just think it is
> the cleaner approach.
>
> regards,
> Sven
>
> PS: No offence meant though.
No offence taken, in the end both is covered by policy and I have not the
slightest problem with either of the alternatives, I just considered full
SUSv3 compliancy to be a low hanging fruit (the "echo -e" calls can be
easily replaced by printf or, more likely, just using lsb-base/
init-functions for its intended purpose).
Just pick your preferred coding style, I don't have much time until
tomorrow evening anyways and wanted to debug #450521 (which will most
likely require rewriting most of the module's buildsystem), #393575
(blocked by a bug in makedev, although I'm not 100% how to make it create
the pipes properly yet) and #471383 (this bug is many fold and overlaps
with #436166/ #471301, lirc is abusing an unexported/ private kernel
interface which has changed significantly recently and probably won't be
easily fixable) over the weekend before looking at the more optional parts
or feature additions.
Regards
Stefan Lippers-Hollmann
signature.asc
Description: This is a digitally signed message part.
