Date: Sat, 27 Apr 2002 17:44:48 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: John Baldwin <jhb@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, Makoto Matsushita <matusita@jp.FreeBSD.org> Subject: Re: cvs commit: src Makefile Makefile.inc1 src/etc Makefile src/ Message-ID: <20020427144448.GJ35685@sunbay.com> In-Reply-To: <20020427081845.GA328@dhcp01.pn.xcllnt.net> References: <20020427033118.GA583@athlon.pn.xcllnt.net> <XFMail.20020427002332.jhb@FreeBSD.org> <20020427081845.GA328@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--EVh9lyqKgK19OcEf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 27, 2002 at 01:18:45AM -0700, Marcel Moolenaar wrote: > On Sat, Apr 27, 2002 at 12:23:32AM -0400, John Baldwin wrote: > >=20 > > Now for a cross-release we need to make sure the binaries in /usr/obj > > in the chroot are cross-built binaries. Ruslan's current approach is > > to do this by make step 3 be a cross-buildworld instead of a full world. > > This means, then, that any tools for the new world you need for 4 > > need to be built as build-tools or cross-tools or the like. What I'm > > suggesting is instead to insert a step at 3.5 to do a cross-build world > > and then we still have the right tools installed and don't have to worry > > about using the right build/cross tools for the release scripts. >=20 > I'm trying to figure out what the implied problem is you're trying > to solve. I think it's the following: >=20 > o Compatibility between the release process and the tools it > uses (including features of the tools it expects). >=20 > This is indeed best solved by doing a full world to populate the > cdroot a second time, but now with bits that match the sources. > The tools and the release are guatanteed to be in sync. >=20 > The drawback is that the new tools may not run on the machine. > Take for example a change in libc that requires a new syscall. > The currently running kernel may not have the new syscall. It's > for this reason that the upgrade process installs a new kernel > before installing world. Thus, a full world step 3 creates a > more dangerous incompatibility than it's trying to solve. >=20 > The approach Ruslan takes is AFAICT the right approach. Of all > the possible incompatibilities, he leaves the incompatibility > between the tools and the release process unsolved. This is > the one developers can maintain by hand in a fairly straight- > forward way and thus the safest one to ignore in the automation. >=20 > Did I extract your concern correctly? >=20 Yes yes yes. As I already wrote, I plan to replace (now OBE) BOOTSTRAPUTILS with some real contents. 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 --EVh9lyqKgK19OcEf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8yrlgUkv4P6juNwoRAtXIAJwL3p/sfqC1j6da3ZdtI5kQSke4HgCghBOy Nqn7zKz979j38FdZCxnjohM= =gmTv -----END PGP SIGNATURE----- --EVh9lyqKgK19OcEf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020427144448.GJ35685>