Bug#208010: Require init.d scripts comply with LSB
On Thu, 29 Jul 2010 16:51:40 -0700, Russ Allbery <rra@debian.org> wrote:
> Please see the bug log for this bug. It was the first thing that
everyone
> objected to.
I read that... and seen no real technical arguments,... just "it would
break things"... and the "argument" that many packages would need to
support this than and to "a lot" of work...
> What are the arguments *in favor* of them?
- Finer grained control on what happens.
- And IMO it's always a good idea to align to reasonable standards (which
don't mean that I support all aspects of LSB ;) )...
- It makes us more homogeneous with other distros or upstream packages
whose intscripts follow LSB... less need to patch.. etc.
> Our
> default should be to not put requirements on packages in Policy; Policy
is
> already long and complicated. We should only be putting requirements in
> packages when doing so solves a concrete interoperability or
> standardization need.
But as I understood,.. it would not work here, to slowly convince
maintainers to use the LSB way here, and then - once the majority did -
adapt the policy (as it happens with dependency based booting). Because
e.g. the exit 5 thingy already conflicts with the policy (well ok it only
says "should" ;) ).
> Certainly, one argument in favor is "so that we comply with LSB." But I
> don't think that is, by itself, sufficient justification
I agree here with you,.. that alone wouldn't suffice...
But I think the finer grained info from the exit statuses is really quite
nicely usable and the same holds true for the status action :)
> to change all the
> init scripts in Debian, particularly given that there's a reasonable
> chance that we'll be moving away from init scripts, at least in part, to
> some other system in the relatively near future given all the other
> drawbacks and deficiencies of the init script system.
That's actually a good point,... but isn't that also a long term thingy?
:D
> That's correct. It's very difficult, and requires a high bar, to
> introduce change into Debian that requires all package maintainers of a
> particular type of package, such as ones with init scripts, to change
> their packages. I think this is a feature, not a bug. We would be
asking
> a lot of people to do a lot of work, and we need to be very clear that
> it's worth it.
Well again,... I don't mean to tell you that I'm smarter than everybody
else,... if we would move towards more conformance here with LSB (I mean
status action, exit status codes) I'd consider it a good change,... but the
world won't stop turning if not.
I believe however, that the section which says initscripts must not fail,
when the package is removed can be a real problem (cryptsetup example).
And even if there is not strong problem,... it's still unlogical IMHO to
not fail then.
If I do e.g. /etc/init.d/service start ... I expect it to be started and
if that didn't work for what ever reason I'd expect an error.
Regardless whether the package is installed or removed :)
> The LSB script headers solved a real problem and let us introduce a
better
> boot system, and the project considered that worth it. It's not at all
> clear to me that the init script status codes have a similar compelling
> use case.
Definitely not that big influence,... IMO it's rather a small but nice
improvement.
> I'm more of an advocate of status, since status is very useful for
> configuration management tools such as Puppet and avoids duplicating
init
> script information to figure out whether a daemon is currently running.
I also like the status action a lot. But I think it will be problematic to
just introduce status, and let the requirement that init-scripts fail not
if the package has been removed.
That's why I meant one could easily catch all three here :D
> I think that's the goal of the DEP process:
>
> http://dep.debian.net/
>> No... see the example with cryptsetup I've described above, where
>> following the policy would open a security problem.
> I don't agree that your example has proven that. It looks theoretical
to
> me, and a stretch to call that a security issue in Debian (as opposed to
a
> misunderstanding by the user of what's required to maintain a consistent
> system). If the user wants to have encrypted devices, they need to not
> remove the packages that handle device encryption.
Well I personally like to compare that with e.g. tools like wipe.
If you say
$ wipe file
you expect the file either to be correctly wiped, or getting an error.
Similar to if you encrypt a file with gpg.
Best wishes,
Chris.
Reply to: