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

Re: /usr/doc issue

> Hi,


My daughter is back home from the hospital, but I'm basically being
a housewife (and responding to emergency calls from work) while my
wife takes care of her.  I hope to be back in the normal swing of 
things by next Monday.  You can wait till then for me to prepare a
ballot or do something to bypass me.  [I'm sorry about the delay.]

On Thu, Aug 19, 1999 at 01:35:38AM -0500, Manoj Srivastava wrote:
>  >> So how do we have major transitions like the one being
>  >> contemplated now? To wit: old policy said that packages follow the
>  >> FSSTND. At some point in the future, we are to follow the FHS. How
>  >> does one modify policy in such a way that would avoid your objection? 

"Raul" == Raul Miller <moth@debian.org> writes:
>  Raul> Why not design the transition so that existing (FSSTND)
>  Raul> packages can be compliant with policy, but so that new packages
>  Raul> can also comply with FHS?

On Mon, Aug 23, 1999 at 11:53:46AM -0500, Manoj Srivastava wrote:
>         Colour me confused. How does this help move the old packages
>  over? If the new packages are to comply with the FHS, and old
>  packages with the FSSTND, we are just prolonging the transition, and
>  we still need something like the symlinks proposal to handle end user
>  frustrations of having the docs and cop[yright files in two places,
>  and Joeys proposal to allow for aprtial upgrades to potato.
>         Am I missing what you mean by ``new packages''?

I meant newly prepared packages -- new package instances.

Also, I wasn't recommending any details here -- just that nothing
should break.

>  Raul> I'm aware that there's a dpkg bug which causes a problem with the 
>  Raul> obvious solution for /usr/doc/, but that seems like not a good reason
>  Raul> to jump in with policy changes which declare every package buggy.
>         One solution is to declare that packages conforming to
>  Standards version 3.X have to move to FHS (modulo exception
>  noted in the policy manual). Packages can still conform to
>  and not be buggy. 

That doesn't solve the interface issue.  There was email to the policy
group before was "ratified" which mentioned examples of debian
packages which would break.

>         Indeed, that is not a satisfoactory solution, since now the
>  bug is ancient standards Version, as lintian helpfully points out.

Among other things, yes.

>  Raul> Debian developers are pretty good about heading towards agreed on
>  Raul> goals, by the way...  [Though with as many packages as we have change
>  Raul> cannot be fast.]
>         In that case, unless the policy dictates the move, I think we
>  have prolonged the transition -- making it harder for us to conform
>  to the LSB, whenever that comes out, and would tend to mark Debian as
>  an old fashioned distribution behind the times (as usual). 
>         It is not as if one were proposing mass bug reports, or even
>  that conformance to standards version 3.0.0 was release critical in
>  any way.
>         Quite frankly, looking at the age of some of the bug reports
>  on major packages, I fail to see what the big deal is about
>  having packages be buggy.

(1) adding more bugs does not get rid of existing bugs.
(2) constitutionally: creating bugs in packages which you're not the
maintainer for exceeds the authority of the debian-policy maintainers.

>         Being constrained to only making policy changes that do not
>  make packages buggy is putting the policy amendment process in a
>  strait jacket that may well be detrimental to the project.

The only strait jacket is that the technical committee is supposed to
ratify such changes.  [And once they've done so or refused to do so 
the developers can override.] 

So the strait jacket is us being slow.

[And, once again, I apologize for being so slow.]


Reply to: