Re: Ports i FreeBSD

From: Flemming Jacobsen (none@fj--batmule.dk.lh.bsd-dk.dk)
Date: Fri 10 Aug 2001 - 08:49:02 CEST


From: Flemming Jacobsen <none@fj--batmule.dk.lh.bsd-dk.dk>
Subject: Re: Ports i FreeBSD
To: bsd-dk@bsd-dk.dk
Date: Fri, 10 Aug 2001 08:49:02 +0200 (CEST)


Dette er 100% FreeBSD specifikt.

jlouis@jlouis.dk wrote:
> Bliver der vedligeholdt et ports tree for 4.x stable samt et for current
> i cvs?

Nej. Der er kun et portstræ (det er derfor du skal bruge 'tag=.'
i din svsup fil).
Dette træ vedligeholdes så det kan bruges på både -current og
-stable. Som regel virker det også 100% på de nyeste -RELEASE's.
Ældre -RELEASE's vil som regel også kunne bruge det nyeste
ports-træ, hvis der blot installeres en update til systemet.
Denne update kan findes på www.freebsd.org/ports .

> Hvis ja, er der noget galt i at tracke current paa en 4.x stable
> kerne (jeg formoder at hvis jeg skal tracke stable ports treet, skal jeg
> have et tag=RELENG_4_3 i min cvsup config file. da jeg ikke har dette,
> formoder jeg, at jeg tracker current).

Nope. Fra: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
  Warning: Be very careful to specify any tag= fields correctly.
  Some tags are valid only for certain collections of files. If
  you specify an incorrect or misspelled tag, CVSup will delete
  files which you probably do not want deleted. In particular,
  use only tag=. for the ports-* collections.

> Nogle pointers til forskellene
> herpaa (jeg kunne gaette paa noget med kun security patches versus det
> nyeste nye hele tiden). Et link ville vaere rart. Havde lidt svaert ved
> at finde noget info omkring det.

Der er kun et træ, så der er ingen forskelle.

Flg. er nok lidt udenfor spørgsmålet, men nu er jeg kommet igang ...

For source-træet gælder:
  RELENG_x_x_x_RELEASE - Testet release. Brug denne hvis du har
    en vigtig produktionsserver, som _skal_ virke. Der kan dog
    stadig være problemer (og ændringer i forhold til tidligere
    releases, der får din specielle setup til ikke at virke), så
    egen test er en god ide.
  RELENG_4_3 (og RELENG_4_4 når den kommer) - Sikkerheds updates
    til RELENG_4_3_0_RELEASE (og hhv. RELENG_4_4_0_RELEASE).
    Burde ikke give problemer, men det er vigtigt at huske at
    disse branch'es _ikke_ får samme gennemgribende test som de
    tilhørende *_RELEASE. For kritiske 24/7 systemer vil egen
    regressions-test bestemt være på sin plads.
  RELENG_4 - Bedre kendt som 4-stable, og for nuværende -stable.
    Denne branch modtager kode fra -current når denne kode har
    vist sig at virke og ikke give andledning til problemer i
    -current. Der er ikke anden test af denne nye kode før den
    kommer i -stable (udover hvad committeren evt. laver på sin
    egen -stable box). Brug af RELENG_4 i 24/7 produktion (eller
    i produktion i det hele taget) kan kun anbefales hvis der
    foretages egen testning inden et nyt snapshot sættes i
    produktion.
    Navnet "stable" er valgt af udviklere. Det implicerer _ikke_
    "stable" som driftfolk forstår ordet.
  . - Bedre kendt som -current. Har intet at gøre på en
    produktions server. Det er _ikke_ c00l at køre -current hvis
    man ikke er udvikler der producerer kode til FreeBSD - det er
    dumt, og det er at tigge om problemer. -current _vil_
    indimellem ødelægge dine data, og den _vil_ indimellem gøre
    dit system ubrugeligt.

Hvis man vælger at opdatere sit sourcetræ og bygge en ny verden
(dvs. compilere og installere nye binaries), så skal man _inden_
man starter læse og forstå det der står i /usr/src/UPDATING.
Dvs.:
        1) Overvej om du vil opadatere baseret på ovenst.
           beskrivelser af de forskellige træer, og diskussion på
           bsd-dk.
           Hvis "ja", så find det træ der passer til dit behov.
           Hvis "nej", så stop.
        2) Lav dig en conf. fil til cvsup. Kig i /usr/share/examples/cvsup
           og i:
           http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
           for info og hjælp.
        3) Lav en backup af dit nuværende sourcetræ.
           Kør cvsup og få opdateret sourcetræet.
        4) Læs /usr/src/UPDATING _grundigt_. Forstå hvad den
           siger. Hvis du ikke er sikker på at du har forstået
           den, så stop her og læg din backup tilbage (ellers kan
           du ikke lave nye kerner).
        5) Overvej om det ikke ville være smart at lave en backup
           af alle relevante data og konfigurations filer.
        6) Følg den i /usr/src/UPDATING beskrevne process for at
           bygge og installere en ny verden.

Punkt 4 er _vigtigt_. Der er ingen der gider høre på folk der
piver fordi de troede at de havde forstået det. Det at bygge og
installere specielt -stable og -current er for erfarne Unix
administratorer. Alle er selvfølgelig velkomne til at
eksperimentere/lege/lære på dette område, men gør det på et
system du kan tåle at skulle reinstallere uden at miste vigtige
data.

Lidt eksempler på build tider:
  På ny hardware (PIII/Athlon 700+MHz, 128M RAM, ny disk(e))
  tager en buildworld 1-2 timer. Installworld tager op til 20-30
  min.
  På min PII-333 med 192M RAM tager det omkring 2.5 time at køre
  en buildworld på 2 hurtige SCSI diske.
  På min K6-200 med 96M RAM (build over 2 diske) tager det omkring
  3.5 time at køre en buildworld.
  Jeg har en vag erindring om at det tog 8-10 timer på min gamle
  486 med 32 eller 64M RAM.
  En 486 med 8M RAM vil nok skulle bruge en uge ...

Buildworld er primært afhængig af CPU og RAM, men hurtige diske
med et forluftigt filsystem layout (/usr/src og /usr/obj på hver
sin spindel) hjælper også.

        FJ

-- 
Flemming Jacobsen                                  Email: fj@batmule.dk
   ---===   If speed kills, Windows users may live forever.   ===---



This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:13 CET