Date: Sat, 3 Jun 2000 07:03:19 +0200 From: Szilveszter Adam <sziszi@petra.hos.u-szeged.hu> To: FreeBSD-Stable <freebsd-stable@FreeBSD.ORG> Subject: Re: restricting installworld to certain distributions Message-ID: <20000603070319.A5745@petra.hos.u-szeged.hu> In-Reply-To: <20000602213532.I2305@speedy.gsinet>; from Gerhard.Sittig@gmx.net on Fri, Jun 02, 2000 at 09:35:32PM %2B0200 References: <20000526211802.X2305@speedy.gsinet> <20000526220454.A3325@student.csd.uu.se> <20000526211802.X2305@speedy.gsinet> <20000526214826.B18664@petra.hos.u-szeged.hu> <20000602213532.I2305@speedy.gsinet>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello! On Fri, Jun 02, 2000 at 09:35:32PM +0200, Gerhard Sittig wrote: > 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. [...] > 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. Well, it is possible that the aforementioned switches (NOSHARE, NOGAMES etc) which very much influence what gets built and what does not, were not present in the 3.x version of /etc/make.conf. Sorry, I can no longer remember. They certainly are in 4.x and -CURRENT, with the only exception that the contents of the file have moved to /etc/defaults/make.conf and /etc/make.conf now only has the overrides. But, as has been said before in this thread, this is not quite what you asked for, it is just similar. Problem is, I still could not think of a better way for a source install. > - 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. Well, although I do not claim to have an intricate knowledge of the make world process, but again... The X11 sources are not present on your system when you install it from sysinstall. X11 does not get updated with a make world, either. The only way to upgrade X is to build the port in /usr/ports/x11 or install the package (which will still go into the correct location at /usr/X11R6, of course) . So X is out of the game:-) As for others, most directories hold what the name says, bin is for /bin, usr.bin for /usr/bin, etc for /etc and so on (although /etc/root contains files that go into /root and /), but there is contributed software in contrib to make your life easier:-) and there is a gnu subdir. The reason from keeping them separate is that contributed software is "on the vendor branch" and therefore different rules apply to committs to those. The gnu subdir holds software from the FSF but sometimes not the files themselves, just the Makefiles which point to locations in contrib. It is easy to figure out what goes where, though: under gnu you have include, lib, libexec, usr.bin and usr.sbin subdirs which about covers it all. Under contrib things get more complicated, but since the subdirs hold individual software packages, you can just look at where does things are now on your system and they will go to the same place later, too. On 4.x and later there is also secure and crypto which hold crytographic apps, but these are not in the base system for 3.x. But yes, the process is quite delicate and is meant to function only the way it is prescribed in the Makefiles (/etc/make.conf just makes setting variables easy.) > - 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. :) Of course, it is your take:-) I have just found things in /usr/share that I have never figured, existed... like flowers in misc... hmmm a UNIX system never gets boring, you know...:-) > - calendar, dict, games look irrelevant Yes. NOGAMES takes care of 'em games. > - doc, examples, info, man don't really miss since they're > available via NFS (lack of examples being noticed most) Good. > - 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 I am not sure for locale, but maybe it gets set to some default if not otherwise specified. I certainly do use it because it is nice to have the computer print dates in Hungarian:-) and of course because it is a workstation. > - pcvt, perl, skel, syscons, tabset, zoneinfo _could_ be > involved in an update and I'm uncertain of the implications Wait... pcvt and perl are not in /usr/src/share... of course, if you do not intend to use the PCVT console instead of the default syscons, it does not need to be updated. But I do not know if it can be turned off separately. (I do not think so.) It is involved for building the kernel, as just about anything else under /usr/src/sys... be careful there. For Perl, there are quite a number of switches, including NOPERL. You have to decide if you use it at all. The others... well, syscons holds keymaps and scrnmaps for different keyboads, probably needed. skel holds some default files for generating things like .cshrc. zoneinfo has the time zone info and gets updated from time to time because governments keep changing to what time zone their country belongs. > - isdn and misc just hold data which are not essentially of > harm when not updated (unless I'm wrong here) No, I do not think they are so important. > - I'm really *scared* about not updating mk and libg++, > especially the former might influence the build and install > process significantly But wait, libg++ is not under /usr/src/share, either... mk is, and is good to keep in an up-to-date shape. > 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? mergemaster only works for /etc, but can be modified to serve your needs. > 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. Well, if you can do this, that would help you, yes... > 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. 'Make release' takes quite some time and needs lots of disk space. And what is worse, it is not always as straight-forward as a 'make world'. Sometimes it does not work at all. I do not think it should be used for 'everyday consumption' although I may be wrong here. The Upgrade menu is suited to your needs, yes. If you do not mind doing a binary-only install, you can upgrade exactly the distributions you have. I have used it for some time before doing make worlds but space is not such a big issue on this machine after all... All you need is a place to get new snapshots from. Since these are available from ftp, there is no problem, the upgrade is as easy as an installation. Hope this helped some more... -- Regards: Szilveszter ADAM Szeged University Szeged Hungary 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?20000603070319.A5745>