Bug#152955: debian-policy: Clarify force-reload, be LSB-compliant in doing so.
On Mon, 10 Jul 2006, Sven Mueller wrote:
> I think we need something like a "policy to be", i.e. some document
> which shows which changes _should_ go into the policy document as soon
> as packages are fixed accordingly. Something that results in an
We can have a "ongoing tasks" page in the wiki, and document where that page
is properly (i.e. at least an email to d-d-a).
That said, you are encouraged to propose a policy change that uses "may",
with a footnote that specifies that it will become a should and must when
the goals of "x% of packages" have been met (I suggest 80% and 98% for the
should and must thresholds). This has been done before, and it works.
> and still not in policy. The reason is simple: Many maintainers don't
> care to implement upcoming policy changes until they really are in policy.
True, and AFAIK the usual way to fix this is do a patch run, followed by a
not-so-friendly prodding for the patch acceptance, and then a NMU to delayed
run. It takes a few months for non-invasive changes, but it is not too
painful. You end up with enough packages fixed to bump policy to a should
without much resistence, and after a few months, another patch run which can
be a lot more forceful will allow it to be brought to a must.
> 1) Implement "force-reload" as a "restart" alias if "reload" is not
> available and violate LSB (which, according to the RMs means an RC
> bug).
Did you specifically ask the RM if this *particular* violation of the LSB
is RC? If you didn't, please clarify it with them.
> 2) Implement "force-reload" as a conditional "restart" alias only
> executed when the service is already running. This violates current
> policy wording and is therefor also an RC bug.
It is also non-trivial to implement. "already running" is not always easy
to detect, and most initscripts are really just crap and don't even do the
start-stop-daemon dance properly.
Usually, if you are going to implement any such thing, it would be good to
implement "status" while at it.
One of the reasons I would get behind a massive workforce to switch to runit
(provided we *still* keep init.d scripts -- they will often be little more
than generic calls into runit helpers and a base initscript shell library
anyway) is that we'd fix all initscripts and maintainers would not have an
excuse to write bad ones anymore because it would be simpler to just do it
right (and runit makes it MUCH easier to track "running state" properly).
> At the very least, I would suggest the following wording of the
> "force-reload" description:
>
> ********************************************************************
> <tag><tt>force-reload</tt></tag>
> <item>cause the configuration to be reloaded if the service supports
> this. If it doesn't support reloading, restart the service. Note that
> the service should not get started if it wasn't already running.</item>
> ********************************************************************
I can second such a change.
> After all, even if policy can't _mandate_ (must, required) the wanted
> behaviour, it should not encourage behaviour that is supposed to get RC
> buggy at some point in time.
That I agree with completely.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: