[debhelper-devel] maintainer scripts and `exit 0`

[Niels Thykier]

Ralf Treinen:
> Hi Niels, hi Lukas,
> 
> On Sun, Jun 18, 2017 at 09:05:00AM +0000, Niels Thykier wrote:
>> Lukas Schwaighofer:
>>> Hi,
>>>
>>> I looked at a postinst script earlier today and realized that an
>>> `exit 0` in maintainer scripts before the commands expanded from
>>> #DEBHELPER# is (almost always) wrong.  That is because the debhelper
>>> inserted code may still want to act, even though the maintainer's own
>>> code is done.
>>>
>>
>> Hi Lukas,
>>
>> Thanks for bring this up. :)
>>
>> CC'ing Ralf: As I recall, he is working on some analysis tool of
>> maintainer scripts and this seems like a good thing to catch.
> 
> Thanks a lot for having thought of us, this looks like a nice application
> for the lintshell tool we are currently developing [1] (this is all very
> fresh, we just finished a first release of the underlying parser, and
> lintshell itself isn't released yet).
> 
> I wonder what would be a reliable way of detecting in the final
> maintainer script (the one which is in the binary package) the portion
> which has been inserted by debhelper. Is checking for 
> 
> "# generated by other debhelper scripts"
> 
> a reliable way to detect that part? How can we detect the end of the 
> part inserted by debhelper?

Any dh_* tool that uses Dh_Lib's autoscript will consistently use:

"""
# Automatically added by ${basename($0)}
<... snippet ...>
# End automatically added section
"""

There is also a python library for this (used by dh_python* as I
recall).  They also start with a similar snippet as they are matched by
lintian's regex: qr{# Automatically added by (\S*[^:\s]):?\s*$}

(I haven't checked if it has a reliable footer though)

> An alternative might be to work directly on 
> the maintainer script snippet in the source package.
>

That would be more reliable for this part of the problem. :)  But then
you get other issues like some cases where people generate their own
snippets to inject at build time (from postinst.in or other template files).

Guess you will have to pick your poison here! :)

>>> I suspect the only exception where the `exit 0` may be justified is
>>> the "triggered" parameter of postinst.  But if we were to allow that,
>>> writing a lintian tag that can reliably detect this problem would
>>> become very hard.
>>>
>>
>> Indeed.
> 
> Hmm, that might be doable since we are working on a concrete syntax tree
> of the shell script, not on the textual level.
> 
> -Ralf.
> 
> [1] https://gitlab.inria.fr/regisgia/lintshell
> 

Seems to require login to access it?

Thanks,
~Niels