Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Dec 2001 00:21:25 -0500
From:      Garance A Drosihn <drosih@rpi.edu>
To:        Ruslan Ermilov <ru@FreeBSD.ORG>
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: Changing 'man' to check alternate destination for 'cat' pages
Message-ID:  <p05101006b83f343ebb2d@[128.113.24.47]>
In-Reply-To: <20011213101401.C77774@sunbay.com>
References:  <20011212001610.9AEA739EA@overcee.netplex.com.au> <p0510100bb83ddfa9e683@[128.113.24.47]> <20011213101401.C77774@sunbay.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101006b83f343ebb2d>