From owner-cvs-etc Thu Jun 5 00:10:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA29672 for cvs-etc-outgoing; Thu, 5 Jun 1997 00:10:15 -0700 (PDT) Received: from labs.usn.blaze.net.au (labs.usn.blaze.net.au [203.17.53.30]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA29665; Thu, 5 Jun 1997 00:10:07 -0700 (PDT) Received: from labs.usn.blaze.net.au (local [127.0.0.1]) by labs.usn.blaze.net.au (8.8.5/8.8.5) with ESMTP id RAA00482; Thu, 5 Jun 1997 17:09:42 +1000 (EST) Message-Id: <199706050709.RAA00482@labs.usn.blaze.net.au> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Jordan K. Hubbard" cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-etc@FreeBSD.ORG Subject: Re: cvs commit: src/etc/mtree BSD.include.dist In-reply-to: Your message of "Wed, 04 Jun 1997 16:50:56 MST." <9703.865468256@time.cdrom.com> X-Face: (W@z~5kg?"+5?!2kHP)+l369.~a@oTl^8l87|/s8"EH?Uk~P#N+Ec~Z&@;'LL!;3?y Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jun 1997 17:09:40 +1000 From: David Nugent Sender: owner-cvs-etc@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Sure, it saves a little space to have the symlinks, but it violates > the idea of having includes be self-contained, something which buys us > far more in being able to update them as a unit at any time and > without odd inter-dependencies on another package which can only cause > additional confusion. Ok. If we go this route - and I have no major objection - can we completely detach builds in /usr/src from hardwired /usr/include and /usr/lib? Possibly others too, like /usr/share/mk. I realise this is more extreme than what you're saying, but if you see where I'm pointing, it'll ultimately make it possible to build a completely different version of the OS on any other version without the runtime dependencies in the installed system, and it should not have any effect on the installed system either. This necessarily means using the compiler, binaries, libs and includes from $DESTDIR consistently throughout the source tree. >From my last attempt to do this, it wasn't really possible without first building the base system into $DESTDIR, chroot and build again; and even then there were no guarantees if the installed OS was markedly different from what you were attempting to build. Only the the basic tools required to build the bootstrap should come from the installed system. In other words, "make release", apart from the distributions building process, would come closer to a one-pass build rather than two full passes as is currently the case. I'm not sure how possible this is or how close we are to being able to achieve it now. All I know is that every time I've tested using alternate $DESTDIR's from "/" I've seen all sorts of subtle breakages. Bruce fixed some gcc related ones recently which were the main culprits (namely special casing old style declarations which typically caused compilation of yacc output to fail here and there), but I haven't tried since then for temporary lack of disk space. I also attempted a few weeks ago to build a 2.2.1 release on a 2.1.7 system. This was less than successful as you can imagine, but after a little fudging to get to the chroot/build stage I was able to get it done. I was under pressure at the time to do it quickly, so unfortunately I wasn't taking notes. :-) I did think that the time that it was theoretically possible to do if only the build process was completely independant from the rest of the system, which seems to be the direction you want to head anyway. Regards, David David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/