Re: /usr/doc issue
> Hi,
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 2.5.0.0
> and not be buggy.
That doesn't solve the interface issue. There was email to the policy
group before 3.0.0.0 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.]
--
Raul
Reply to: