Josip Rodin wrote:
Sorry, I lost you there. Is that to make us believe FHS transition was proper or improper, necessary or unnecessary, or what? :)
No, I only wanted to show that it has been impossible the get major Policy changes accepted in the past 4 years. It's not that there haven't been any innovative proposals (mostly on debian-devel), it's just that you get an objection if you propose more than a clarification or an addition to the list of virtual packages. In most cases the submitter of the proposal loses interest in other proposals (or his whole Debian work) after getting a lot of objections.
This means that the only innovation in Debian in the past 4 years has been more packages (or newer versions) and more architectures. Improving the init scripts to at least catch up with other major distributions (status option, exit codes, chkconfig, colored output on supported consoles, ...) is less work than e.g. adding another architecture -- but it requires consensus among developers. When a package does not build on a new architecture you can file an RC bug and the maintainer has to fix it (or you can NMU). But you can't do this for new features unless Policy prescribes them. So if Policy only documents common practice, we are stuck.
Therefore I suggest to accept changes to the Policy even if this means that some packages suddenly violate the Policy. This of course only makes sense when the required infrastructure (e.g. a features in dpkg) is already there and the proposed change has proven to work correctly in other packages (reference implementation).
Probably only if you file bugs without any rationale. If not, those maintainers need some attitude readjustment.
Ok, let's test this: I'll file 10 bug reports with example code and explanation against packages with init scripts that use start-stop-daemon asking the maintainer to add the status option and adjust the return code according to the current proposal. I really fear that I will not be very successful unless this becomes part of the Policy, even if I submit patches. But we'll see...
Stefan