sslug-teknik team mailing list archive

[Troels Arvin <troels@xxxxxxxx>]

Emil S Hansen wrote:
> Enig, men det er sk* alfa og omega at man dokumentere alt hvad man laver
> af ændringer på systemet, ellers burde man sku ikke være ansat som
> admin. (IMHO)
Jeg siger ikke, at man ikke skal søge at dokumentere sit system. Jeg
siger, at man skal søge at anvende værtøjer, der minimerer behovet for
dokumentation. Igen: Jeg synes, at du lyder meget verdensfjern. Det
tager evigheder at dokumentere ordentligt, hvis man i detaljer skal
beskrive, hvorledes en større software-pakke er installeret; det slipper
du for med pakke-systemet: her kan du nøjes med at dokumentere
konfigurations-filernes indhold (evt. med indlejrede kommentarer) samt
evt. ikke-standard-valg, du har truffet.

For at holde din kategoriske stil, vil jeg mene, at en
system-administrator øjeblikkeligt skal fyres, hvis han/hun ikke søger
at anvende standard-værtøjer til at øge systemets gennemskuelighed.

> du altid kan finde sourcen til gamle versioner af Open Source
> projekter, ergo kan du også finde sourcen til den (gamle) version du har
> installeret nu, ergo kan du finde Makefilen.
Makefilen beskriver ikke nødvendigvis enhver placeringen på enhver fil i
software-pakken.

Og makefiler giver dig heller ikke mulighed for fx. at sige:
Jeg har fil /x/y/z - hvilken software-pakke er den mon del af?

Og hvad hvis du gerne lige vil vide, hvilke filer som er ændrede siden
installationen af en given software-pakke?

> Hvad er forskellen på en .rpm pakke som du har hentet fra nettet og en
> .tar.gz fil som du selv har kompillert?
Kender du overhovedet RPM-systemet?

> jeg har det sådan at jeg MEGET gerne
> vil vide hvordan programmet bliver konfiguret, startet op, kørt osv.
> osv.
Fint. Jeg forstår bare ikke, hvordan du får tid til at sætte dig
ordentligt ind i dokumentationen, når du skal sidde og fedte med al den
kompilering. Hvad lærer man af at en given pakke skal have en særlig
configure-option i fald din XXX-YYY er særligt på AAA-BBB-vis? Jeg vil
vove den påstand, at man kunne lære mere interessante ting...

> Og så er der jo lige det med compiletime options, hvor vil du finde en
> .rpm til php3 som har support for gd, imap, ftp, pop3 men IKKE MySQL?
> Eller en hver anden kombination?
Hvis man har helt særlige behov kan man være nødt til at bryde
pakke-principperne. Eller omdefinere pakke-specifikationen og bygge en
ny binær pakke; det er faktisk piece of cake, og man beholder da
systemets pakke-mæssige integritet.

Mht. PHP og PHP-extensions:
I Red Hat's "rawhide" distribution er lagt op til en ret god måde at
håndtere PHP-extensions: Der er en basal PHP-pakke, som man installerer;
hvis man så også har behov for fx. PostgreSQL-understøttelse,
installerer man blot PHP-pgsql-pakken, og php3.ini opdateres automatisk
med en reference til et ekstra library.

Jeg forventer, at denne måde at håndtere PHP og PHP-extensions bliver
standard i kommende Red Hat versioner. Den er det muligvis allerede i
andre distributioner.

Der er så et problem med MySQL, fordi MySQL ikke er 100% åben software.
Dette gør at Red Hat ikke med-leverer en PHP-MySQL pakke, men det kunne
være oplagt for andre at gøre.

> Det tager måske 30-60 mins længere at kompillere en .tar.gz pakke
Eller adskillige timer, hvis vi fx. taler XFree86.
Gang det med de måske 200 pakker, som en mindre Linux-distribution
efterhånden består af, og det vil tage en uges tid at installere en
Linux-maskine.
Jeg forstår ikke, hvorfor det skulle være fedt!!


PS:
Det kan være interessant at kompilere visse software-pakker med
CPU-specifikke optimeringer, hvis softwaren bruges meget og der er tale
om regne-intensive opgaver. Dette kan sagtens gøres uden at bryde éns
pakke-administrations-system. Hvis vi taler RPM-systemet, sker det vha.
.src.rpm-pakker; jeg indrømmer dog gerne, at RPM-systemet kunne
forbedres her.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark