On Sun, 29 Jun 1997, Jim Pick wrote: > One complication I can think of - dselect and the ftp sites have the > concept of "overrides", where Guy can change the section a package > is assigned to. This wouldn't be reflected in the /usr/doc > directory - of course, this might not really matter.
I think it does matter, as an undesired source of confusion. It'd be a bad thing to have docs for foo in /usr/doc/utils/foo, for example, if foo is in section devel and not section utils. On Sun, 29 Jun 1997, Brian White wrote: > From a "use" point of view, the user knows what package documentation > he's looking for when going into /usr/doc, so why does a large directory > make any difference? > > Let's leave it the way it is. Splitting it will only make things more > difficult for users. someone else (I missed the aqttribution) said: > > > The directory is very large when you have a lot of packages > > > installed, and it takes a lot of processing to open it with a file > > > manager, web browser, or dired. > > > > I completly agree. I have 434 items in /usr/doc, and that's too many. > > Splitting it up by package section is a very good idea. I'd agree that a directory with over 400 items in it is probably excessively unwieldy. How about creating directories /usr/doc/[a-z], and putting package doc files into subdirs based on the initial char of the package name? That would reduce the unwieldiness of /usr/doc with less potential for confusion. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .