[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

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: