Path: utzoo!attcan!uunet!cs.utexas.edu!mailrus!wuarchive!texbell!nuchat!moray!splut!jay
From: jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard)
Newsgroups: news.software.b
Subject: Re: C news: file ownership and running build 47386 times
Message-ID: <1989Nov19.204554.21808@splut.conmicro.com>
Date: 19 Nov 89 20:45:54 GMT
References: <3054@splut.conmicro.com> <1989Nov19.001714.25018@utzoo.uucp>
Reply-To: jay@splut.conmicro.com (Jay "you ignorant splut!" Maynard)
Organization: Confederate Microsystems, League City, TX
Lines: 44

In article <1989Nov19.001714.25018@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>>Which user id should unshar the C news sources?
>>Which user id should own the programs?
>>Which user id should run build?
>The generic answer is "it depends on what you want".  On utzoo, the answer
>is the same for all three:  "bin".  You should definitely run build, and
>the programs it creates, as someone who has permission to write in the
>source directories (e.g., the uid that unsharred the sources).  It is
>convenient to have the programs (except the two setuid ones) owned by
>the source owner.  If there is no uid that has permission to write on
>both the source directories and the programs, you will have to compile
>as one user and then do the installation as another.  (The current build
>warns you about this.)

I finally wound up:
find . -exec chown bin {} \;
build
su
doit.root
su bin
sh; unset _; doit.bin (because of a bug in Microport make)
^d^d su usenet
sh; unset _; doit.news
^d^d again.root
...which ran everything as expected. I ignored the "can't change foo"
messages from build, since they'd already been changed before. (I
couldn't run build as bin because it'd dump core. argh.)

>This is coming.  Just to clarify:  this will *not* be a "configuration file"
>that you can edit, it will merely be a way to have build use your last set
>of answers as the defaults for a new run.

That's all I'm asking for - remember the last answers as the defaults
for the new answers, a la Larry Wall's Configure stuff.

BTW, it seems to work well with dbz 1.9 (I found my copy - in
/usr/spool/news, of all places) and no INCORE defined (per the comment
about 16 bit systems).

-- 
Jay Maynard, EMT-P, K5ZC, PP-ASEL   | Never ascribe to malice that which can
jay@splut.conmicro.com       (eieio)| adequately be explained by stupidity.
{attctc,bellcore}!texbell!splut!jay +----------------------------------------
Shall we try for comp.protocols.tcp-ip.eniac next, Richard? - Brandon Allbery