From owner-freebsd-stable Fri Jun 2 19:18: 7 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id 0F03637B7C2 for ; Fri, 2 Jun 2000 19:17:59 -0700 (PDT) (envelope-from Gerhard.Sittig@gmx.net) Received: (qmail 29805 invoked by uid 0); 3 Jun 2000 02:17:55 -0000 Received: from p3e9e7958.dip.t-dialin.net (HELO speedy.gsinet) (62.158.121.88) by mail05.rzmi.gmx.net with SMTP; 3 Jun 2000 02:17:55 -0000 Received: (from sittig@localhost) by speedy.gsinet (8.8.8/8.8.8) id VAA07739 for freebsd-stable@FreeBSD.ORG; Fri, 2 Jun 2000 21:35:32 +0200 Date: Fri, 2 Jun 2000 21:35:32 +0200 From: Gerhard Sittig To: FreeBSD-Stable Subject: Re: restricting installworld to certain distributions Message-ID: <20000602213532.I2305@speedy.gsinet> Mail-Followup-To: FreeBSD-Stable References: <20000526211802.X2305@speedy.gsinet> <20000526220454.A3325@student.csd.uu.se> <20000526211802.X2305@speedy.gsinet> <20000526214826.B18664@petra.hos.u-szeged.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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 +0200 Organization: System Defenestrators Inc. Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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