Re: /usr/doc issue
Hi,
>>"Raul" == Raul Miller <moth@debian.org> writes:
Raul> 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> Why not design the transition so that existing (FSSTND) packages can be
Raul> compliant with policy, but so that new packages can also comply with
Raul> FHS?
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''?
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.
Indeed, that is not a satisfoactory solution, since now the
bug is ancient standards Version, as lintian helpfully points out.
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.
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.
manoj
--
Fishing, with me, has always been an excuse to drink in the
daytime. Jimmy Cannon
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: