Re: /usr/share/doc vs. /usr/doc transition, debate reopened
On Tue, Aug 03, 1999 at 09:35:52AM -0700, Joseph Carter wrote:
> On Tue, Aug 03, 1999 at 07:41:26AM -0400, Michael Stone wrote:
> > That's simple enough. This all only works if there is no /usr/share/doc
> > and you can move /usr/doc in an atomic operation.
>
> Your assessment is flawed---it assumes facts like /usr/share and /usr/doc
> being on the same partition. You cannot have an atomic move in this case.
In which case you leave things in /usr/doc and put the symlink from
/usr/share/doc and let the admin handle it if he sees fit. Having
/usr/doc or /usr/share on a separate partition is a site-specific
decision, and I think it's reasonable to have the appropriate admin
decide what to do in this case.
> > IMHO, packages that
> > started using /usr/share/doc were premature in that usage and shouldn't
> > get special accomodation. For now, packages should be built to install
> > into /usr/doc without concern for whether that's a symlink or not. We
> > can worry about whether we want to deal with the symlink at a later
> > date.
>
> Ignore the problem and it'll go away? feh.
Is it the end of the world if there's a symlink from /usr/doc to
/usr/share/doc? Will the sky fall, or will there be other similarly
important reasons for dealing with it immediately? I think what we've
really learned here is that we need some flexibility in dealing with
this sort of thing. If we want to get rid of that symlink, we need a way
to create an appropriate dependency. Some people have suggested putting
a depends: base-files-whatever in _every_ debian package for the rest of
time. I'm not sure that's a clean approach. (I think it would be nicer
to abstract this more: packages already have to indicate what
policy-version they comply with, why not use that information to set the
appropriate dependency?) Until we have a clean way of dealing with this
problem, I don't see what harm there is in not jumping the gun. You can
spit juvenile responses like "feh" at me all you want, but that doesn't
help resolve this mess.
> We put off the archive restructure discussion until hamm was released, but
> it never got addressed until we were gearing up for slink release and was
> put off again. Now it's come up still again in time for it to be put
> aside until potato's release.
So what? (I'm quite serious here: I'm still trying to understand what
the problem is.) Are we trying to shove things out, or are we trying to
get things right? If you come up with a clean solution, you might get
things closer to a resolution. Complaining that people aren't working
fast enough for you won't speed things up.
Mike Stone
Reply to: