From owner-p4-projects@FreeBSD.ORG Sun Feb 1 19:10:12 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DC1AA106566C; Sun, 1 Feb 2009 19:10:11 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8AE106564A for ; Sun, 1 Feb 2009 19:10:11 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [IPv6:2001:4f8:fff6::29]) by mx1.freebsd.org (Postfix) with ESMTP id 879A28FC13 for ; Sun, 1 Feb 2009 19:10:11 +0000 (UTC) (envelope-from rene@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.14.3/8.14.3) with ESMTP id n11JAB4S034615 for ; Sun, 1 Feb 2009 19:10:11 GMT (envelope-from rene@FreeBSD.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.14.3/8.14.3/Submit) id n11JABns034613 for perforce@freebsd.org; Sun, 1 Feb 2009 19:10:11 GMT (envelope-from rene@FreeBSD.org) Date: Sun, 1 Feb 2009 19:10:11 GMT Message-Id: <200902011910.n11JABns034613@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to rene@FreeBSD.org using -f From: Rene Ladan To: Perforce Change Reviews Cc: Subject: PERFORCE change 157001 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Feb 2009 19:10:12 -0000 http://perforce.freebsd.org/chv.cgi?CH=157001 Change 157001 by rene@rene_self on 2009/02/01 19:09:55 MFen handbook/cutting-edge 1.239 -> 1.240 Affected files ... .. //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#20 edit Differences ... ==== //depot/projects/docproj_nl/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml#20 (text+ko) ==== @@ -5,7 +5,7 @@ $FreeBSDnl: doc/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml,v 1.47 2006/01/07 11:27:42 siebrand Exp $ %SOURCE% en_US.ISO8859-1/books/handbook/cutting-edge/chapter.sgml - %SRCID% 1.239 + %SRCID% 1.240 --> @@ -1722,10 +1722,217 @@ De universele wijze om een systeem bij te werken - Een systeem bijwerken kan met de volgende procedure, nadat - /usr/src/UPDATING is geraadpleegd om te - controleren of er voor buildworld voor de gebruikte versie van - de broncode nog acties zijn uit te voeren: + Om uw systeem bij te werken, dient u + /usr/src/UPDATING te controleren op + eventuele pre-buildworld stappen die nodig zijn voor uw versie + van de broncode en daarna de procedure te gebruiken die hier + beschreven staat. + + Deze bijwerkstappen nemen aan dat u nu een oude versie van + &os; gebruikt, die uit een oude compiler, een oude kernel, een + oude wereld en oude instellingenbestanden bestaat. Onder + wereld worden de binairen, bibliotheken, en + programmeerbestanden van het kernsysteem verstaan. De compiler + is deel van wereld, maar heeft enkele speciale + aandachtspunten. + + We nemen ook aan dat u reeds de broncode van een nieuwer + systeem heeft verkregen. Bekijk, als de bronnen op een bepaald + systeem ook oud zijn, voor uitgebreide + hulp over het synchroniseren ervan naar een nieuwere + versie. + + Het bijwerken van het systeem vanaf de broncode is wat + subtieler dan het op het eerste gezicht lijkt, en de + ontwikkelaars van &os; vonden het in de loop der jaren nodig om + de aangeraden methode redelijk drastisch te veranderen met het + aan het licht komen van nieuwe soorten onontwijkbare + afhankelijkheden. De rest van deze sectie beschrijft de + rationale achter de huidige aanbevolen bijwerkmethode. + + Elke succesvolle bijwerkmethode krijgt te maken met de + volgende punten: + + + + Het kan voorkomen dat de oude compiler de nieuwe kernel + niet kan compileren. (Oude compilers bevatten soms bugs.) + De nieuwe kernel dient dus met de nieuwe compiler gebouwd te + worden. In het bijzonder moet de nieuwe compiler gebouwd + worden voordat de nieuwe kernel gebouwd wordt. Dit betekent + niet per se dat de nieuwe compiler + geïnstalleerd moet worden voordat + de nieuwe kernel gebouwd wordt. + + + + De nieuwe wereld kan afhankelijk zijn van mogelijkheden + van de nieuwe kernel. Dus moet de nieuwe kernel worden + geïnstalleerd voordat de nieuwe wereld wordt + geïnstalleerd. + + + + De eerste twee gevallen zijn de basis voor de methode + buildworld, + buildkernel, + installkernel, + installworld die we in de volgende + paragrafen beschrijven. Dit is geen uitputtende lijst van alle + redenen waarom het huidige aanbevolen bijwerkproces de voorkeur + verdient. Wat minder voor de hand liggende redenen worden + hieronder genoemd: + + + + Het kan zijn dat de oude wereld niet correct draait op + de nieuwe kernel, dus moet de nieuwe wereld onmiddellijk na + het installeren van de nieuwe kernel geïnstalleerd + worden. + + + + Sommige instellingen moeten veranderd worden voordat de + nieuwe wereld wordt geïnstalleerd, maar anderen kunnen + de oude wereld kapot maken. Vandaar dat over het algemeen + twee verschillende bijwerkstappen voor de instellingen nodig + zijn. + + + + Voor het grootste gedeelte houdt het bijwerkproces zich + alleen bezig met het vervangen of toevoegen van bestanden; + bestaande oude bestanden worden niet verwijderd. Dit kan in + sommige gevallen problemen geven. Als een gevolg zal de + bijwerkprocedure soms aangeven dat bepaalde bestanden + tijdens bepaalde stappen handmatig verwijderd dienen te + worden. Dit kan in de toekomst eventueel geautomatiseerd + worden. + + + + Deze zorgen hebben tot het volgende aanbevolen bijwerkproces + geleid. Merk op dat het gedetailleerde proces voor bepaalde + updates aanvullende stappen nodig kan hebben, maar dit + kernproces zou de komende tijd ongewijzigd moeten + blijven: + + + + make buildworld + + Dit compileert eerst de nieuwe compiler en enkele + aanverwante gereedschappen, daarna wordt de nieuwe compiler + gebruikt om de rest van de nieuwe wereld te compileren. Het + resultaat komt in /usr/obj te staan. + + + + make buildkernel + + In tegenstelling tot de oude aanpak, die &man.config.8; + en &man.make.1; gebruikt, gebruikt dit de + nieuwe compiler die in /usr/obj verblijft. Dit + beschermt u tegen mismatches tussen de compiler en de + kernel. + + + + make installkernel + + Plaatst de nieuwe kernel en kernelmodules op de schijf, + waardoor het mogelijk wordt om met de nieuw bijgewerkte + kernel op te starten. + + + + Start opnieuw op in enkele-gebruikersmodus. + + De enkele-gebruikersmodus minimaliseert problemen met + het bijwerken van software die al draait. Het minimaliseert + ook problemen die opduiken door een oude wereld op een + nieuwe kernel te draaien. + + + + mergemaster + + Dit voert wat initiële updates aan + instellingenbestanden uit ter voorbereiding op de nieuwe + wereld. Het kan bijvoorbeeld nieuwe gebruikersgroepen aan + het systeem, of nieuwe gebruikersnamen aan de + wachtwoorddatabase toevoegen. Dit is vaak nodig wanneer er + nieuwe groepen of speciale accounts voor systeemgebruikers + zijn toegevoegd sinds de laatste keer bijwerken, zodat de + stap installworld zonder problemen + de nieuw geïnstalleerde namen van systeemgebruikers of + systeemgroepen kan gebruiken. + + + + make installworld + + Kopieert de wereld van /usr/obj. U heeft nu een + nieuwe kernel en een nieuwe wereld op schijf staan. + + + + mergemaster + + Nu kunt u de overgebleven instellingenbestanden + bijwerken, aangezien u een nieuwe wereld op schijf heeft + staan. + + + + Start opnieuw op. + + Een volledige nieuwe start van de machine is nodig om de + nieuwe kernel en de nieuwe wereld met nieuwe + instellingenbestanden te laden. + + + + Merk op dat als u van de ene uitgave van dezelfde tak van + &os; bijwerkt naar een recentere uitgave van dezelfde tak, i.e. + van 7.0 naar 7.1, dat deze procedure dan niet absoluut nodig is, + aangezien het onwaarschijnlijk is dat u serieuze problemen + krijgt met de compiler, kernel, gebruikersland en + instellingenbestanden. De oudere aanpak met make + world gevolgd door het + bouwen en installeren van een nieuwe kernel kan voor kleine + updates goed genoeg zijn. + + Maar mensen die deze procedure niet volgen tijdens het + bijwerken tussen grote uitgaven kunnen wat problemen + verwachten. + + Het is ook goed om op te merken dat veel upgrades (i.e. + 4.X naar 5.0) wat specifieke + aanvullende stappen nodig hebben (bijvoorbeeld het hernoemen of + verwijderen van specifieke bestanden voorafgaand aan + installworld). Lees het bestand + /usr/src/UPDATING zorgvuldig, met name het + einde, waar het huidig aangeraden bijwerkproces expliciet wordt + beschreven. + + Deze procedure is in de loop der tijd veranderd aangezien de + ontwikkelaars zagen dat het onmogelijk was om bepaalde + mismatch-problemen volledig te voorkomen. Hopelijk blijft de + huidige procedure voor een lange tijd stabiel. + + + Het bijwerken van &os; 3.X of + eerdere uitgaven is wat lastiger; lees + UPDATING zorgvuldig door als u zo'n soort + upgrade moet uitvoeren. + + + Samengevat is de huidige aanbevolen manier om &os; vanaf + broncode bij te werken: &prompt.root; cd /usr/src &prompt.root; make buildworld