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
