Date: Fri, 2 Jun 2000 21:35:32 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: FreeBSD-Stable <freebsd-stable@FreeBSD.ORG> Subject: Re: restricting installworld to certain distributions Message-ID: <20000602213532.I2305@speedy.gsinet> In-Reply-To: <20000526214826.B18664@petra.hos.u-szeged.hu>; from sziszi@petra.hos.u-szeged.hu on Fri, May 26, 2000 at 09:48:26PM %2B0200 References: <20000526211802.X2305@speedy.gsinet> <20000526220454.A3325@student.csd.uu.se> <20000526211802.X2305@speedy.gsinet> <20000526214826.B18664@petra.hos.u-szeged.hu>
next in thread | previous in thread | raw e-mail | index | archive | help
My question was this:
On Fri, May 26, 2000 at 09:18:02PM +0200, Gerhard Sittig wrote:
>
> This is a questions about how to restrict installworld in a
> way, so that only the formerly installed distributions get
> copied.
... and quite a long scribble followed, involving a "development
workstation" with cvsup'ed sources and NFS exported buildworld
results as well as an underpowered (for compilation) router with
installworld over NFS ...
The biggest problem was disk space concerns leaving the machine
at the edge of workable state since installworld copied over
manpages and docs and stuff which wasn't (binary) installed in
the first place. This led to the following questions:
> I guess you already know what I want to ask: Is there a way to
> just update the installed software "no matter how voluminous
> the /usr/src tree is"? Is there a way for installworld to have
> a look at the installed distributions? Or is there a way of
> "binary updating" the smaller machine which I just didn't find
> out about up to now?
To summarize what has been said by the helpful people on this
list:
On Fri, May 26, 2000 at 21:48 +0200, Szilveszter Adam wrote:
>
> Uhm... I do not think there is a way to restrict 'make
> installworld' apart from the knobs in /etc/make.conf, which
> prevent some components from building in the first place (like
> sendmail) but those are more for the case when you've got your
> own replacements for those and don't want them to be
> overwritten... Which seems like an obvious problem. However, I
> think that a binary upgarde can handle this well, because you
> only select what you want to upgrade when running sysinstall.
> Of course you can always fiddle with cd-ing into individual
> directories in the /usr/src tree and doing 'make install's
> there but I feel these to be wildly unsupported and in fact can
> see quite a number of cases when they can plainly hose the
> system or create problems (a major upgrade being one of them
> but not the only one.)
>
> [ ... ]
And in addition he pointed me towards mergemaster(8) and the
updated handbook (available even in separate translations) to
save me from doing the /etc diff and updates by hand -- at least
in the "straight" cases. :) Thanks!
On Fri, May 26, 2000 at 22:04 +0200, Erik Trulsson wrote:
>
> > [ ... what I did so far ... ]
>
> With 3.4-stable updating '/etc' can/should be done using
> mergemaster instead. Otherwise you seem to have followed the
> recommended procedure.
>
> [ ... ]
>
> You can't do quite what you ask for but almost. If you look
> in /usr/src/Makefile.inc1 you will find some flags for 'make'
> to control what is/isn't built/installed.
> For example: 'make -DNOSHARE -DNOINFO -DNOGAMES installworld'
> will skip all manpages (and everything else that goes into
> /usr/share) and all .info files and also the stuff in
> /usr/games. You can also add -DNOPROFILE to avoid installing
> the profiled libraries. That should leave a pretty minimal
> system.
So I would go and back up the router's current state and install
3.3-R from scratch - to get a known and consistent state - and
make installworld to 3.4-S with the above mentioned switches.
Yet there are still some thinks I'm unsure about:
- /etc/make.conf won't reveal anything to restrict installation
of previously installed distributions, but only hinders ports
and the base system from collision in the very few cases where
single very well selected packages (or programs) made it into
the base - like bind and sendmail and co. This is clearly
stated above and was known before.
- I somehow fail to "map" the bin/doc/man/src/x11 distribution of
the binary install to the /usr/src subdirectories and I feel
it's because they don't relate directly but get formed by make
actions moving things from one directory into several places or
the other way round, moving files from several subdirs into the
same installed place. And as Adam puts it quite clear this
procedure is very error prone and quite an effort.
- So Erik's way seemed the most promising -- until I did a 'du -s
/usr/share/*' and found some dirs that could be of interest and
might need some attention. Unless you tell me I'm wrong and I
don't have to care too much. :)
- calendar, dict, games look irrelevant
- doc, examples, info, man don't really miss since they're
available via NFS (lack of examples being noticed most)
- groff*, locale, nls, tmac are easy to live without(?) since
the doc is not installed and is't not a workstation with
humans sitting in front of them
- pcvt, perl, skel, syscons, tabset, zoneinfo _could_ be
involved in an update and I'm uncertain of the implications
- isdn and misc just hold data which are not essentially of
harm when not updated (unless I'm wrong here)
- I'm really *scared* about not updating mk and libg++,
especially the former might influence the build and install
process significantly
So it turns out that I will end in doing something like this:
make -DNOSHARE -DNOINFO -DNOGAMES installworld
ls /usr/share > list1
ls /mounted_usr/share > list2
DIRS_NEW_IN_SHARE=$( diff list? | some_formatting )
for DIR in $DIRS_OF_INTEREST; do
diff -r /usr/share/$DIR $MOUNTED/share/$DIR
do_patches_or_copies
# should I extend mergemaster here?
done
for DIR in $DIRS_NEW_IN_SHARE; do
dir_is_not_important && continue
copy_them_over
done
The easiest solution for me seems to be to free up another 120MB
disk from the Linux router (since it's to be replaced anyway with
the "new" machine) and use this one as /usr, leaving enough space
for a "mostly unrestricted" make installworld with more
distributions than just bin and secure.
I'm almost certain none of the "in the know" people have the
resources to spend hours or even days just for the rare case
where single megabytes count and binary installation is not an
option. That's where I tend to follow the easier route. The
effort of splitting installworld to finer grain even seems to not
pay in the end -- disk space is so cheap today when installing
anything new and even older machines usually have a few hundred
of megabytes to offer. I guess it's not the regular situation
these days to just have 100MB for it all.
BTW Can it be that "make release" and /stand/sysinstall's
Upgrade menu item is the proper or better suited solution and I
just didn't get it? Will it be worth the hassle to shuffle some
data and free up space for building a -SNAP to install from?
Although doing so will take quite some time so my feedback on
this definitely will delay substantially.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000602213532.I2305>