On Thu, 29 Jul 2010 16:51:40 -0700, Russ Allbery <r...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
