[OE-core] [PATCH] update-rc.d.bbclass: check that init script exists before running it

[Andreas Oberritter]

On 06.10.2016 17:12, Phil Blundell wrote:
> On Thu, 2016-10-06 at 16:46 +0300, Markus Lehtonen wrote:
>>
> It was moved to prerm earlier to fix some other problems:
>> http://git.openembedded.org/openembedded-core/commit/meta/classes/upd
>> ate-al
>> ternatives.bbclass?id=2a5484a90513b58c829a916bfe5268a0fde3512a
> 
> The commit message for that checkin is a bit vague about exactly what
> problem it was solving.  It mentions that it "fixes deinstalling
> alternatives for programs needed by the postrm script, e.g. /bin/sh"
> but it's rather hard to see how that actually works.  If postrm
> requires /bin/sh and prerm has deleted it then it's not obvious how
> this is an improvement.

Sorry for the bad commit message back then.

If you had both busybox and bash installed and had /bin/sh pointing to
bash, then uninstalling bash failed, because the postrm script was
started with a dangling symlink of /bin/sh.

The commit cited above fixes it, because when the prerm script finishes,
/bin/sh will point to busybox, thus letting the postrm script of bash
succeed.

> 
>> So I think moving it back and forth between prerm and postrm doesn't
>> get us
>> anywhere :)
> 
> That is a fair point, though I am not entirely convinced that the
> commit you mentioned above is the correct solution to whatever problem
> it thinks it's solving.
> 
> As it stands, with both things in prerm, you will get essentially
> random behaviour depending on the order in which the two classes (u-
> rc.d and u-a) are inherited by the recipe.  If u-a comes first then u-
> rc.d will not be able to run the "stop" script (and the services will
> not be stopped on package uninstallation), and vice versa.
> 
> So maybe these two classes just need to be taught to play together
> better.

I think having update-alternatives manage an initscript is already a bug
on its own. I haven't seen such a thing in debian or anywhere else
before. Update-alternatives usually creates symlinks for programs which
can be installed side-by-side. If two system services provide the same
functionality, I guess the packages should better conflict with each
other or at least have different initscript names (like apache2 and
lighttpd for example), so they can both be started with adjusted
configurations (e.g. using different tcp ports).

Regards,
Andreas