[Pkg-lirc-maint] Bug#471422: Bug#471422: lirc: bashism in /bin/sh script

[Stefan Lippers-Hollmann]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-lirc-maint/attachments/20080319/8a642eb5/attachment-0001.pgp