From owner-freebsd-arch Thu Dec 13 21:21:36 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 37A3A37B405; Thu, 13 Dec 2001 21:21:31 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fBE5LTO37440; Fri, 14 Dec 2001 00:21:30 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011213101401.C77774@sunbay.com> References: <20011212001610.9AEA739EA@overcee.netplex.com.au> <20011213101401.C77774@sunbay.com> Date: Fri, 14 Dec 2001 00:21:25 -0500 To: Ruslan Ermilov From: Garance A Drosihn Subject: Re: Changing 'man' to check alternate destination for 'cat' pages Cc: freebsd-arch@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:14 AM +0200 12/13/01, Ruslan Ermilov wrote: >On Thu, Dec 13, 2001 at 12:01:03AM -0500, Garance A Drosihn wrote: > > I noticed there are some changes to 'man' in release 5 which haven't been > > MFC'ed yet. Would there be any reason those should not be MFC'ed? > >Some of them can't be MFC'ed, some can be. Please be specific. :-) "Being specific" would require that I actually know what I'm talking about. I can be much quicker if I stick to being vague! :-) I was just noticing the changes to man/man.c and man/Makefile. Seems to be something about Avoid using setre[ug]id() calls. Removed the setgid stuff we don't need. (a few) about locale handling I only mentioned them because man/man.c is probably the source file I'd have to change if I were to implement the changes I am talking about, and if I did do these changes then I would like to MFC my own changes. That's easier (IMO) if I can MFC the changes which came before them. > > Should I try my hand at implementing my idea, or is someone else > > already looking into it? > >Sorry, but I don't quite understand what are you looking at. >We already have a manpath(1) facility, that could be used >to configure alternate manual pathes. Is that not sufficient? > > I haven't done any work on this yet, I'm just looking for feedback. >> >What's the goal of doing this? I missed the original thread. It started in the thread about getting rid of the need to have /usr as a separate partition. If we could get /usr so it was very close to "read-only" in standard operation (*), then we could do away with creating a separate partition for it in the default partition-choices. We would just roll it into the partition for '/', and create '/' at a larger size to match. I kinda like this idea. When I have a 20-gig disk, it seems a shame to burn up a limited-resource like "available partition letters" on a 50 or 100-meg partition. (just my opinion) (* - by "standard operation" here, I mean in normal day-to-day usage. Obviously it would be written to when installing ports into /usr/local, and things like that). Someone else then mentioned that if /usr *is* a part of '/', then we don't have to statically-build all the binaries in /bin or /sbin. It was noted that this saves several megabytes in the size of the system, and that such savings are welcome in some situations (embedded systems, older machines, etc). So, as one way to make /usr more "read-only" for all users, without adversely effecting anyone, I thought it would be nice if 'man' knew how to save the 'cat' pages for (say) /usr/share/man/man* into some place under /var. My thought was /var/man/usr/share/man/cat* While I have thought of doing this on my own machines with symlinks, I think that gets pretty messy pretty fast. So, I thought the least disruptive change would be if 'man' used such directories *if* they had been created by the administrator (or install-process), but if those new directories did not exist then 'man' would behave exactly as it does now. Another way to get the effect of a "more read-only" /usr would be to do a catman step every time one does an installworld. Me, I hate the idea of using catman to address this specific issue (although it may be fine to do for other reasons). For one, I do a lot of installworlds, and I am not looking for ways for installworld to take MORE time! Second, if one of my hopes is that we can *shrink* the executables in /bin or /sbin (because we will not have to statically-link them), then it seems counter-productive to reduce that disk space by chewing up a whole lot of disk space by storing all the cat pages. Given that background, my previous message should make a bit more sense. At least, I hope it does... :-) I guess one argument against my idea is that it means that the files in /var/log will be in the same partition as the arbitrary-amount of files from 'cat' pages. Perhaps this is not a good idea. I'm sure I could think of other objections if I really tried, but I hate arguing against my own ideas so I'm seeing what other developers think. I know that this one change will not turn /usr into a read-only directory, but it would be one step towards that goal. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message