Hi all
After processing, tackling and implementing all remarks Michael gave about previous version, I hereby present you v2 of this patchset. As the other patchset that I submitted, containing small cosmetic changes on services.cgi, depended on v1 of this patchset; I have now included those changes in this set instead of reposting those again as a seperate set. Those cosmetics (patch 3-5) are not part of the fix for bug#12935.
I'm quite confident that the code of addonctrl is now much better/cleaner by implementing and handling Michael's concerns. There is now even more errorchecking going on (mainly for system errors).
I know Core 171 went in Testing, but as there currently are already 2 bugreports concering this fix (#12916 was also linked to this today); I'm assuming quite a few IPFire users are currently experiencing problems with the services.cgi page. So, if possible and feasable, I think it would be a good idea to try to include this one in CU171 (at least patch 1 and 2) ?
If there are still concerns/remarks about this new version, I'll try to handle them asap.
For reference, the content of the summary mail that was sent with v1 of the patch: --- This patchset fixes Bug#12935 (https://bugzilla.ipfire.org/show_bug.cgi?id=12935)
Summary: Addons where the initscript does not match the addon-name and addons with multiple initscripts are now listed on services.cgi since CU170. But addonctrl still expected addon name to be equal to initscript name; Hence starting/stopping/enabling/disabling of such addons was not possible. This has always been like that, but that problem was hidden as services.cgi also did not display those addon services.
After discussing this with Adolf on the Bug report, we concluded that we should adapt addonctrl to work with the new addon metadata Services-field instead.
I basically rewrote addonctrl to not only use the new services metadata but also to have better errorchecking and added the posibility to check if a service is currently enabled or disabled. As a result services.cgi no longer has to go checking the precense of runlevel initscripts, but can just ask addonctrl. I also added a warning to services.cgi if a runlevel initscript does not exists, to prevent the user from wondering why he can't enable a specific service. (Adolf pointed out some services don't install runlevel initscripts by default)
More details in the bugreport and in the commit-messages of the patches. ---
Regards Robin