Re: Bug#208010: [PROPOSAL] init script LSB 1.3 compliance (revised)
On Tue, 02 Sep 2003 00:58:32 +0200, Stefan Gybas <sgybas@debian.org> said:
> [Directly answering to -policy, this does not need to be archived in
> the BTS.]
> Henrique de Moraes Holschuh wrote:
>> Tested patches against all init-script using packages to the BTS.
> So from now on, we'll only change Policy after all packages comply
> with the proposed changes?
Yes. This is how policy has always worked; too.
> We'll never make large progress if it's handled this way.
But we have managed to do so in the past, by providing a
transition plan. First, you recommend the change, and work on getting
packages changed over. Then you make the new way the default, but not
a must condition, deprecating the old one. And finally, you can
mandate the new way.
> And how do we implement incompatible changes?
Allow both, but not mandate either the old or the new
one. Then make the new one the default; and so on.
If the packages done the new way can't live with packages done
the old way, well, you need to arrange for a flag day, when all the
packages change, probably by creating a staging area.
> Implementing a proposed change first before modifying Policy makes
> sense if we need a special feature in a single package like dpkg or
> menu (update-menus) but not if a lot of packages should offer a new
> feature like in this case. Implementing status for init scripts is
> not difficult in most cases since "start-stop-daemon --test" already
> offers this feature. The move to /usr/share/doc or the addition of
> build dependencies were also specified in Policy before all packages
> had a patch in the BTS.
You need to get packages changed, which they can do in advance
of policy; policy can then be changed to reflect the new reality.
You can not use policy changes to beat people on the head with.
> Isn't this what Standards-Version: is for? Packages specify which
> version of the Debian Policy they comply with and at some point in
> time the RM defines the minimal Policy version for a release. The
> severity of bugs is raised if a package's standards version is too
> low.
Wrong. There is only one policy, the current one. The
standards version is to help the developer keep track of hwat
changes need to be made to make the package compliant -- you look at
the upgrade checklist since the version in the package,
> Making this change to Policy does not mean than all packages must
> change their init script immediately, or did I misunderstand
> something?
You have indeed misunderstood how policy process works, and
what the standards version means.
manoj
--
You tread upon my patience. William Shakespeare, "Henry IV"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: