Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Hi, On 14-12-2020 22:43, Sean Whitton wrote: On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote: 'not fail' here means that the script terminates with return code 0. This is how I would read it too. Would a patch to add "(i.e. exit with return code 0)" resolve the original submitter's concerns? Though I'm still not convinced it's a sensible requirement, that clarification would resolve my main concern (i.e. having to fix init scripts to work with an absent defaults file). By the way, there's an identical requirement a few paragraphs before, so it might be good to insert the same clarification there as well. Cheers, Oxan
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Hello, On Tue 15 Dec 2020 at 06:02PM +01, Oxan van Leeuwen wrote: > Hi, > > On 14-12-2020 22:43, Sean Whitton wrote: >> On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote: >>> 'not fail' here means that the script terminates with return code 0. >> >> This is how I would read it too. Would a patch to add "(i.e. exit with >> return code 0)" resolve the original submitter's concerns? > > Though I'm still not convinced it's a sensible requirement, that > clarification would resolve my main concern (i.e. having to fix init > scripts to work with an absent defaults file). By the way, there's an > identical requirement a few paragraphs before, so it might be good to > insert the same clarification there as well. Okay, cool. Patches welcome! -- Sean Whitton signature.asc Description: PGP signature
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Hello, On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote: > On Mon, Nov 30, 2020 at 02:37:08PM +0100, Oxan van Leeuwen wrote: >> Source: debian-policy >> Version: 4.5.1.0 >> Severity: normal >> >> Currently Policy requires that init.d scripts, and only init.d scripts, don't >> fail if the corresponding /etc/default is removed (section 9.3.2, >> second-to-last >> paragraph). >> >> Personally I interpret "not fail" as "succeed to function", i.e. it has to >> actually start the daemon. I don't think that's a particularly sensible >> requirement. > > 'not fail' here means that the script terminates with return code 0. This is how I would read it too. Would a patch to add "(i.e. exit with return code 0)" resolve the original submitter's concerns? -- Sean Whitton signature.asc Description: PGP signature
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
On 30-11-2020 19:28, Ansgar wrote:> I think we should keep the
requirement. Legacy init.d scripts are still
handled as conffiles and kept around even if the package is removed
(unlike systemd unit files). Thus init scripts are still run[1] and
should behave sensibly.
For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors. So the init script still needs to
do something sensible (probably just do nothing).
I don't think this requirement is necessary to handle that case. There
is already a separate, explicit requirement for init scripts to not fail
for removed-but-not-purged packages a few paragraphs before, and Policy
explicitly states init scripts should use ``test -f daemon || exit 0''.
[1]: For packages shipping native .service files for systemd, this
might mean that for removed-but-not-purged packages suddenly the
sysvinit script gets started? After all there is no longer a .service
files to prefer over the sysvinit script...
At least for packages using debhelper that's not the case, as
dh_installsystemd (and its predecessor dh_systemd_enable) mask the
service on package removal.
Cheers,
Oxan
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
On Mon, Nov 30, 2020 at 02:37:08PM +0100, Oxan van Leeuwen wrote: > Source: debian-policy > Version: 4.5.1.0 > Severity: normal > > Currently Policy requires that init.d scripts, and only init.d scripts, don't > fail if the corresponding /etc/default is removed (section 9.3.2, > second-to-last > paragraph). > > Personally I interpret "not fail" as "succeed to function", i.e. it has to > actually start the daemon. I don't think that's a particularly sensible > requirement. 'not fail' here means that the script terminates with return code 0. Cheers, -- Bill. Imagine a large red swirl here.
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Oxan van Leeuwen writes:
> Currently Policy requires that init.d scripts, and only init.d scripts, don't
> fail if the corresponding /etc/default is removed (section 9.3.2,
> second-to-last
> paragraph).
[...]
> The other option is that "not fail" means that the init script is allowed to
> not
> start the daemon, but it shouldn't cause any further breakage. That seems
> like a
> sensible requirement to me, but the wording could use some clarification in
> this
> case.
I think we should keep the requirement. Legacy init.d scripts are still
handled as conffiles and kept around even if the package is removed
(unlike systemd unit files). Thus init scripts are still run[1] and
should behave sensibly.
For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors. So the init script still needs to
do something sensible (probably just do nothing).
(There are other problems as a sysvinit script cannot really be a noop
for removed-but-purged packages as the LSB header still does something,
but improving that is probably not too welcome as it would require
changes in sysvinit.)
Ansgar
[1]: For packages shipping native .service files for systemd, this
might mean that for removed-but-not-purged packages suddenly the
sysvinit script gets started? After all there is no longer a .service
files to prefer over the sysvinit script...
Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted
Source: debian-policy Version: 4.5.1.0 Severity: normal Currently Policy requires that init.d scripts, and only init.d scripts, don't fail if the corresponding /etc/default is removed (section 9.3.2, second-to-last paragraph). Personally I interpret "not fail" as "succeed to function", i.e. it has to actually start the daemon. I don't think that's a particularly sensible requirement. Policy doesn't require programs to function if their native configuration files are removed, so why should default files be any different? Furthermore, this requirement doesn't exist for systemd unit files, and there are in fact unit files in the archive that fail if the default file is removed. Also, to me removing configuration files seems like a "don't break your system" kind of action. If the system administrator does it, they get to keep the pieces and are reponsible for the fallout. The other option is that "not fail" means that the init script is allowed to not start the daemon, but it shouldn't cause any further breakage. That seems like a sensible requirement to me, but the wording could use some clarification in this case.
