Re: /usr/share/doc: some new proposals
Hi. Sorry to stick my oar in again.
On Wed, Aug 04, 1999 at 01:11:06AM -0500, Manoj Srivastava wrote:
> Hi,
> >>"Chris" == Chris Waters <xtifr@dsp.net> writes:
>
> Chris> There is more involved with FHS than I think many people
> Chris> realize. We have a fair amount of work to do just with the
> Chris> stuff that is obvious *and* non-contentious, like
> Chris> /usr/share/man and /usr/share/info. I
>
> That is already policy.
Given any policy change that is non-trivial, many packages in the
archive are going to be non-compliant and the time to implement the
change is going to be substantial (this is probably obvious by now).
I think it is a Bad Idea to start thinking about kludges to fix an
otherwise policy-inconsistent archive at release. Time must be made.
[[Aside: I would suggest a rule of thumb, say something like: "A
policy change which requires n% of the archive to be updated should be
instigated before (100-n/2)% of the time between releases has passed."
This can be achieved by delaying the release or delaying the policy
change. In the /usr/share/doc case, the policy change (that is, the
timetable for policy document change, lintian change, issuing of bug
reports etc.) should have been sorted out before the halfway
point. Just an idea.]]
> Chris> haven't heard *anyone* discuss the move from /var/lib/games to
> Chris> /var/games either, which is going to require a bit of work.
>
> What is wrong with individual packages moving to /var/games as
> part of FHS compliance? What are the problems you envisage?
Peoples' score files (analogous to "documentation") are no longer
where they expect them. This is not so serious. However, the save
files need to be moved "manually" as they are not part of any
package. So for /var/games, we really do need some carefully tested
maintainer script template.
> Chris> Potato is *not* going to be FHS compliant, so why pretend?
I agree. Ideally, policy and archive should agree at release time. If
necessary, change policy to reflect this (postpone the harder changes
to just after release). Or just live with it.
> I think you are labouring under a misapprehension here. No one
> is saying that potato shall be FHS compliant. We would be hard put to
> make woody compliant, I think, if we start now. But I think moving
> towards FHS compliance is important, and can be done.
not FHS compliant => not policy compliant => send a bug report
I hardly think we need be bashful about lots of bug reports. I don't
think I have seen the suggestion:
a) change packaging tools (lintian, debhelper, etc.) (takes a week?)
b) weekly? msg to devel-announce (re. /usr/share/doc and new tools)
c) one month? before freeze, file important? bugs against violators
Changing policy and sending out bug reports has worked in the past.
> Chris> The /usr/doc issue is big, but it's simple and consistent, and
> Chris> will yield to brute force measures *somehow*. Let's make sure
> Chris> we have the more subtle, inobvious, and tricky bits under
> Chris> control before worrying about it.
>
> Which are?
He possibly meant things like:
1. users with /usr/doc/ or /usr/share/ in their own partition are
in for a bit of a shock (not much we can do about this)
2. any complicated solution will have complicated failure cases
("Why Things Bite Back", Edward Teller?)
3. if we want a guaranteed upgrade path "forever", then cruft in
maintainer scripts will stay around "forever" (as in dpkg's)
Giuliano.
ps I haven't mentioned symlinks until now, just say no!
Reply to: