Meer controle met zelf compileren?

[Kaastosti]

Tijdens het leren met linux kom je veel handleidingen tegen die je vertellen hoe je zelf een stuk software moet configuren, compilen en installeren. Dat is heel erg handig, heel erg mooi en je hebt volledige controle over wat er op je syseem komt te staan.

Als ik hier de FAQ lees en een aantal topics er bij pak, lees ik dat de meeste mensen toch meer gecharmeerd zijn van een package manager, aangezien er dan op 1 plek wordt bijgehouden wat er geinstalleerd staat. Ook kun je op die manier makkelijker software weer verwijderen.

Nu heb ik hier op m'n stage bij het installeren van een aantal servers, gebruik gemaakt van apt-get (ja, het is dus debian). Daarbij worden zoveel mogelijk opties geinstalleerd en dus ben ik er dan van verzekerd dat zoveel mogelijk gaat werken (bijv. bij apache met php en mysql).

M'n stagebegeleider echter zweert er bij om alles handmatig te configuren en compilen, omdat dit volgens hem meer controle geeft. Nu zie ik zelf ook wel dat je dan compleet zelf opgeeft welke stukjes je wel en niet wilt hebben, dus 100% controle. Mijn vraag is echter of je diezelfde mate van controle ook niet kunt krijgen met een package manager.

Als ik bijvoorbeeld na installatie van apache een dpkg-reconfigure van apache doe, krijg ik een hele lijst modules die ik aan en uit kan zetten, waarna de apache config aangepast wordt. Is dat te vergelijken met een handmatige installatie, of geeft dat toch nog niet de controle die in sommige gevallen gewenst is?

[Spider.007]

Op zich is je vraag vrij eenvoudig te beantwoorden. Handmatig compilen geeft je inderdaad meer controle en zekerheid van wat je installeert. Wat hier tegenoverstaat is het gemak van upgraden via een packagemanager. Handmatig compilen is 3 keer leuk; maar daarna geloof je het ook wel. Dat is dus precies wat een packagemanager hoort te voorkomen Je wil zelf niet telkens controleren op de website van de fabrikant of een package is geupdate; daar gebruik je je packagemanager voor. Compileren is trouwens meer dan alleen modules dis/enablen; zo zul je vaak machinespecifieke optimalisatievlaggen kunnen meegeven

[esf]

In Gentoo Linux kan je door middel van USE flags aangeven welke opties moeten worden gebruikt bij het compileren van package. En daarbij wordt gebruik gemaakt van een package manager. Je kan waarschijnlijk minder opties wijzigen dan bij handmatig compileren, maar toch een aantal per software pakket.
Bij Gentoo wordt gebruik gemaakt van een packagemanager, maar deze compileert wel alle pakketten. Daarom zijn ook optimalisaties mogelijk.

[ Voor 19% gewijzigd door esf op 15-04-2005 11:31 ]

[Tony Vroon]

Je hebt met zelf compileren inderdaad meer controle. Je ziet ook dat in debian veel packages staan die bijna hetzelfde zijn qua naam, maar dus iets anders gecompileerd zijn.

(Net tussen debian's package manager en *alles* handmatig compileren heb je nog de portage package manager die in Gentoo zit. In plaats van het handmatig aansturen van de configure scripts zet je USE-flags aan of uit.)
Je zit vast aan hetzelfde nadeel als alles handmatig compileren, het duurt langer.

[ Voor 2% gewijzigd door Tony Vroon op 15-04-2005 11:31 . Reden: En esf heeft gewonnen :( ]

[Kaastosti]

Okee dat klopt ongeveer wel met wat ik al verwachtte. Voor gebruiksvriendelijkheid met betrekking tot installatie en updaten is de package manager een uitkomst, maar voor echte controle ben je toch gebonden aan zelf compileren.

Dan weet ik in ieder geval dat ik dat nog even goed in de vingers moet krijgen, want zo'n package manager is wel mooi, maar je leert er uiteindelijk maar weinig van natuurlijk

[A_L]

Soms moet je zelf wel compileren omdat een package niet beschikbaar is voor je platform. Het beste is eigenlijk om er daarna zelf een package van te maken (.deb of .rpm). Zodat het makkelijk te beheren/verwijderen is.

[Kaastosti]

Maar het beheer van een .deb wordt er toch niet makkelijker op op het moment dat je deze via de package manager zou installeren? Het eventueel later verwijderen wel, maar qua beheer zal de package manager er toch ook weinig mee kunnen omdat het een custom compiled stuk software is?

[A_L]

Jawel het is dan net zo te beheren als alle andere "officiele" packages. Verder kun je het op meerdere systemen gaan gebruiken.

[Kaastosti]

Als het goed begrijp zijn er dus een serie settings die je alleen met zelf compilen voor elkaar kan krijgen, en een gedeelte wat ook door de package manager aan te passen is. Als je daar een eigen .deb van maakt zijn die compile settings dus vast, waarna je alsnog op ieder systeem met de package manager dingen aan kan gaan passen?

[irondog]

Zelf compileren (zonder package manager) is iets voor ontwikkelaars of prutsers die denken te weten wat ze doen. Bij verkeerde handelingen krijg je allerlei zooi versnipperd over je systeem, of kom je vroeg of laat er toch weer achter, dat je iets vergeten bent mee te nemen bij het aanroepen van ./configure

Zo is make install bijna nooit terug te draaien. Wat Gentoo met USE-flags doet, kun je trouwens ook gerust nadoen met RPM door hier en daar wat dingen in de SPECfile te veranderen. Daarmee zijn RPM distro's eigenlijk veel kleiner en compacter te houden dan wat Gentoo standaard meelevert. Gentoo kent namelijk geen afsplitsing tussen devel packages en core packages. Het hele "controle"-verhaal is gewoon een kwestie van smaak.

Voor productie zou ik dus zeggen: ga niet zelf (wederom: zonder package manager) liggen compileren. Je zult zelf namelijk nooit zo goed een buildprocess kennen als mensen die zich daar lang en grondig in verdiept hebben. En als deze mensen hun werk goed doen, is zelf compileren per definitie overbodig.

[ Voor 9% gewijzigd door irondog op 15-04-2005 12:32 ]

[Kaastosti]

M'n stagebegeleider heeft al wel ervaring met zelf compileren, alle servers draaien met zelf gecompilede software. Wat dat betreft komt het dus wel goed, maar ik vroeg me af of je diezelfde controle ook met een package manager kan krijgen... en de conclusie van dit topic is dat dat dus niet het geval is.

Dat controle een kwestie van smaak is lijkt me niet echt. Het feit dat je zelf compile argumenten op kan geven getuigd ervan dat er dus voorgeprogrammeerde stukken zijn (dus geschreven door de mensen die er verstand van hebben), die 'aan' gezet moeten worden en daarbij misschien een variabele nodig hebben.

Mijn voorkeur gaat ook uit naar een package manager, maar er zijn kennelijk dingen die niet via die weg kunnen. Voor zolang het niet nodig is wijk ik ook niet van mijn goede vriend apt-get af, maar er gaat dus een punt komen waarop ik zelf moet gaan klooien

[irondog]

En wat je dan beter kan doen is een debian package schrijven naar je smaak. Alles is beter dan als root bashen en installeren (en een jaar later niet meer in je bash histrory terug vinden hoe je het ook alweer gedaan hebt).

Waarom de package manager:
* deinstalleerbaar
* upgradebaar (je hoeft alleen je ebuild, SRPM of .deb aan te passen)
* veranderbaar (je hebt spijt van je manier van builden, je verandert je script, en voila een nieuwe build naar wens).

Laatst ook een mailtje gehad van een vriend van me. Kon met apache geen modrewrite gebruiken. Een of andere gek heeft dus gedacht zelf dit O-ZO bekende opensource programma zelf slimmer te kunnen compilen dan de makers van debian. En zie daar het resultaat: je hebt 'meer controle', maar je doel wordt niet bereikt.

[mOrPhie]

Overigens zijn er wel manieren om je source-tarbals te managen. "Stow" geeft je de mogelijkheid de sources te installeren, te updaten, te wijzigen en te bekijken wat er geinstalleerd is en dergelijke. Eigenlijk alles wat een moderne package-manager kan, maar dan met source-tarbals.

Lees er hier meer over: http://www-106.ibm.com/developerworks/linux/library/l-stow/

Ik heb het zelf ooit 'ns geprobeerd en het is zeker de moeite waard als je alles vanaf sources wilt installeren.

[irondog]

Ik kan begrijpen dat je het op bepaalde punten niet eens kan zijn met de packager van je distro, maar dan pas je toch gewoon zijn werk aan. In gentoo heb je een PORTDIR_OVERLAY voor zelf geschreven ebuilds. Bij RPM distro's heb je source RPMS en SPECs die kinderlijk eenvoudig aan te passen zijn. Zo zul je bij debian ook wel mogelijkheden hebben.

Ik moet eerlijk toegeven dat het meer werk kan zijn, maar het betaalt zich echt terug. Zelfs bij het eenvoudigste programma kun je keuzes maken in het compileer process en fouten, geloof me, je zult ze maken. Maar je kunt beter een script schrijven om je stappen te 'onthouden' dan een beroep doen op je lange termijn geheugen. Ooit wil je toch weer updaten ofzo. Bovendien kunnen make (als root) en make install vieze dingen doen met je omgeveing.

[Cyphax]

irondog schreef op vrijdag 15 april 2005 @ 12:31:
Zelf compileren (zonder package manager) is iets voor ontwikkelaars of prutsers die denken te weten wat ze doen. Bij verkeerde handelingen krijg je allerlei zooi versnipperd over je systeem, of kom je vroeg of laat er toch weer achter, dat je iets vergeten bent mee te nemen bij het aanroepen van ./configure

Zo is make install bijna nooit terug te draaien.

Ik compile de helft zelf en de andere helft gaat via de package manager: pkgtool samen met swaret.
Het voordeel daarvan is uiteraard dat er bijgehouden wordt welke software is geinstalleerd en je kunt het vrij makkelijk updaten of uninstallen. Maar om maar te zeggen dat zelf compileren iets voor prutsers of ontwikkelaars is... overigens krijg je pas zooi versnipperd over je systeem na make install, en hoe vaak gaat dat nou fout? Daar komt bij dat make uninstall meestal ook wel gaat, toch?
Soms kun je ook niet veel anders. Kijk naar mplayer; er wordt aangeraden zelf te compilen, en anders moet je een contributed package ofzo gaan zoeken, maar als daar iets mis mee is moet je maar net documentatie hebben. Als je de dependencies voor elkaar hebt kun je het meeste best goed zelf compilen. Ik in ieder geval wel. Als prutser
Uiteindelijk gaat mijn voorkeur wel uit naar installeren via de packagemanager. En waarom ook niet.

[irondog]

Cyphax schreef op vrijdag 15 april 2005 @ 13:32:
[...]

Ik compile de helft zelf en de andere helft gaat via de package manager: pkgtool samen met swaret.
Het voordeel daarvan is uiteraard dat er bijgehouden wordt welke software is geinstalleerd en je kunt het vrij makkelijk updaten of uninstallen. Maar om maar te zeggen dat zelf compileren iets voor prutsers of ontwikkelaars is... overigens krijg je pas zooi versnipperd over je systeem na make install, en hoe vaak gaat dat nou fout? Daar komt bij dat make uninstall meestal ook wel gaat, toch?

Dat valt ontiechelijk zwaar tegen. Zelfs make install is zelden genoeg om iets netjes te installeren (zie de ebuilds of SPECS van de duidenden packages die hun ronde doen op het www). Laat staan deinstalleren. Dat van die 'prutsers' moet je misschien meer lezen als 'tweakers'

Soms kun je ook niet veel anders. Kijk naar mplayer; er wordt aangeraden zelf te compilen, en anders moet je een contributed package ofzo gaan zoeken, maar als daar iets mis mee is moet je maar net documentatie hebben. Als je de dependencies voor elkaar hebt kun je het meeste best goed zelf compilen. Ik in ieder geval wel. Als prutser

Met mplayer noem je ook wel ff wat. Veel distro's weigeren om mp3 spelers of programma's die windows dlls vereisen op te nemen in het standaard pakket (terwijl dat wel vaak is wat je wil). Mplayer is trouwens een heel goed voorbeeld om mijn bovenstaande argumenten kracht bij te zetten: Je kan het ontiechelijk tweaken. Van uitgebreide allesspeler tot videoplayer voor embedded systems. Geen kattepis iig en dus zeker niet iets waar ik mijn zusje voor inschakel om het te builden. En als je het zelf doet, dan kom je snel op je eigen werk terug omdat het niet toerijkend is.

Uiteindelijk gaat mijn voorkeur wel uit naar installeren via de packagemanager. En waarom ook niet.

Ik ben te verwend met Gentoo's portage. Ik hoef eigenlijk nooit uit te wijken.

edit:
verduidelijking

[ Voor 12% gewijzigd door irondog op 15-04-2005 14:10 ]

[Verwijderd]

Ik gebruik Slackware en die heeft geen uitgebreide hoeveelheid packages dus moet ik wel regelmatig dingen zelf compileren. Wat ik zelf altijd doe is installeren met checkinstall. Je doet dan zelf `./configure && make`, en vervolgens `checkinstall make install`. Checkinstall maakt dan een package van wat er zou gebeuren met make install en installeert vervolgens die package. Hij kan iig slackware (.tgz) en debian packages maken, ik dacht ook rpm.

Voordeel is dat je en de controle van zelf compileren hebt, en het gemak van een package manager mbt installeren en deinstalleren, en je hebt een package van wat je zelf geinstalleerd hebt wat je weer kan gebruiken op een andere machine, of kan bewaren als backup. En je hoeft de source niet te bewaren om `make uninstall` te doen.

Zelf gebruik ik eigenlijk alleen officiele slackware-packages en zelf gecompileerde packages. Packages van andere, derde, partijen vertrouw ik nooit zo, dan geef ik altijd de voorkeur aan zelf compileren.