Date: Fri, 16 Aug 2002 03:40:04 -0700 (PDT) From: Ruslan Ermilov <ru@FreeBSD.org> To: freebsd-bugs@FreeBSD.org Subject: Re: i386/30276 Message-ID: <200208161040.g7GAe4T7054469@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/30276; it has been noted by GNATS. From: Ruslan Ermilov <ru@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Larry Rosenman <ler@lerctr.org>, Bruce Evans <bde@FreeBSD.org> Subject: Re: i386/30276 Date: Fri, 16 Aug 2002 13:29:39 +0300 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2002 at 01:39:27PM -0700, Marcel Moolenaar wrote: > On Thu, Aug 15, 2002 at 08:45:05PM +0300, Ruslan Ermilov wrote: > > >=20 > > > One problem with linking them shared is that they are not self-contai= ned > > > anymore. What you get is this. Suppose install(1) is linked shared. It > > > runs fine, because it's built to run on the machine anyway. Now, as p= art > > > of installworld we install a brand new libc. Boom. Not only can we br= eak > > > a parallel installworld, we can also break the install process at lar= ge > > > by having a libc that doesn't work anymore. > > >=20 > > No booms here. We're requiring to install new kernel first. >=20 > There doesn't necessarily have to be a kernel dependency. The FILE > related changes that were made early this year are a very good > example of how things can blow up even with an up-to-date kernel. >=20 > > > Another reason for the -noshared is that it allows us a single-pass > > > upgrade path. With this I mean an upgrade path that builds world, > > > builds a kernel, installs a kernel, installs world, mergemaster-like > > > work and finally a reboot. > > >=20 > > This is not an approved way, and 4.0 can't be upgraded such a way. >=20 > Correct; but it was were I was heading :-) >=20 > > > Thirdly, people tend to build on their fastest machine and then do the > > > install on the machine they originally build for. By building the too= ls > > > staticly, you have a higher chance that it works. Especially if they > > > build on -stable and do the actual install on -current. > > >=20 > > You'd have to be running with compat.4x libs enabled then. >=20 > Sure, but it would reduce the self-containedness of an installworld if > people would have to install compat4x first. Chances are they select > it as part of a world, but I don't think we install the compat libraries > before anything else, do we? >=20 > > > Note that this > > > is currently not really supported, because we don't really deal with = the > > > CPU optimization stuff > > >=20 > > We build them with -DNO_CPU_CFLAGS nowadays. >=20 > Ok, cool. I didn't know this. >=20 > > > and we also don't rebuild tools if they can not > > > be used on the install machine (or even at all). > > >=20 > > My proposal is an attempt to relax this restriction. The only restrict= ion > > left (I should have said this earlier) is that libraries on the install= ing > > host should be feature-compatible with the corresponding libraries on t= he > > installing host. (Hmm, but this is often not the case, especially in t= he > > libc version bump case.) >=20 > I think it's better to conditionally rebuild the tools. We could > easily avoid using yacc/bison, flex, gcc and other "build" tools > during installworld, so the set should be small and the tools > should be simple. The advantage of having a mechanism that > triggers the rebuild of certain tools is that you can probably > integrate the copying of native tools to a temp. dir as > we do now. The added advantage is that you can build instead > of copying. >=20 > You can probably look at it as being a bootstrap phase for > installworld. It allows us to resolve runtime compatibility problems > (missing features or incompatible default behaviour) and other > warts... >=20 > Anyway: this is mostly from the top of my head. I haven't actually > given this any real thought. It may as well be utter nonsense :-) >=20 No, this is not nonsense. That was actually my plan too, but I thought that this may be a better idea. Now I see that it isn't. (See Bruce's email on the topic for more provoking things.) I planned to tidy the buildworld/installworld list of tools that we use anyway, and analyse some usage statistics, so I will probably stick this task on the top of it (because first I need to determine a full set of tools that we need during installworld). Cheers, --=20 Ruslan Ermilov Sysadmin and DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9XNQTUkv4P6juNwoRAjnoAJ9OvtogUNohvh4ZxF+Uhe6Qz9Kl7gCbB9ZZ iiNfusFfQH2uoUaXTuxb9Nc= =u6lB -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200208161040.g7GAe4T7054469>