Gå til innhold

BSD/Unixhvordan "deconfigure" i freebsd


Anbefalte innlegg

Om jeg har brukt "./configure" og så "make" for å installere apache i freebsd, hvordan avinstallerer eller oppdatererer jeg Apache etterpå da? er det bare å slette mappen "/usr/local/apache/", og så kjøre configure på nytt?

 

Her er kommandoen jeg kjørte:

 

./configure 
--prefix=/usr/local/apache \ 
--with-mpm=worker \ 
--enable-so \ 
--enable-cgi \ 
--enable-info \ 
--enable-rewrite \ 
--enable-speling \ 
--enable-usertrack \ 
--enable-deflate \ 
--enable-ssl \ 
--enable-mime-magic \ 
--enable-module=expires \ 
--enable-module=proxy make

Endret av illshit
Lenke til kommentar
Videoannonse
Annonse

Mente du "make uninstall" fra "/usr/local/apache/"?

 

Jaja, pakkesystemet er bra, men jeg har hørt man får mer kontroll over ting når man installerer manuelt.

 

Blir det det samme som "./configure" når man tar "make config" i f.eks. "/usr/ports/www/apache22/"?

Lenke til kommentar

ports blir som å installere fra kildekode bare med kontroll, det er absolutt anbefalt å bruke ports! gidder du ikke kompilere pakkene selv finnes de fleste i ferdigkompilert tilstand.

 

Og som nevnt så bruker du make uninstall fra sourcemappa, men så skal det sies at jeg aldri har hatt behov for å bruke den kommandoen. Skal du lage noe fra kilde lønner det seg etter min mening å lage en pakke som man så installerer slik at man har noen lunde kontroll på innmaten. Gjør du ikke dette blir det grisete, og du kommer til å angre om noen år når du må formatere.

 

For bruk av ports så sjekk freebsdmanualen den er kjempebra, men det gjøres ca likt som fra source bare at noen pakker er tweaket litt slik at man lettere kan velge alternativer med menysystemer (om man vil bruke det så klart)

Lenke til kommentar

i linux blir ikke alt alltid lagt i en mappe, men det blir gjerne spredt rundt om kring ettersom hva slags filer det er. Derfor trengs det en fil for å holde styr på hvor alle filene har blitt av. Makefila som du bruker når du kompilerer inneholder av og til denne infoen, men ikke alltid. Slik at de gangenedu ikke kan kjøre make uninstall så sliter du litt.

 

Mens en pakke har en slik fil uansett og kan enkelt fjernes fra systemet med en kommando og du er alltid sikret et bra resultat. Det samme gjelder ports. Forskjellen på ports og pakker er at pakker er ferdidgkompilerte mens ports er oppskrifter på hvordan pakker fungerer slik at du kan kompilere fra source men fortsatt ha muligheten til å oppgradere, og styre pakker på en enkel måte selv om du konfigurer pakkene etter behov. Det er dette som er så genialt med ports.

 

De to tingene jeg savner i linux er pf og ports så bruk disse verktøyene godt ;)

Lenke til kommentar

Det fine med ports er at kildekoden blir patchet med modifikasjoner dersom det er nødvendig og alle dependencies kommer med for at det skal fungere.

"make install clean" er en grei kommando. Det er også mulig å kjøre andre kommandoer for å få gjort enkelte ting.

 

make fetch

make config

make patch

make

make install

make deinstall

make reinstall

 

make config sine instillinger blir lagret i /var/db et sted og blir husket til neste compile.

 

ta også en titt på ting som "portsnap". Her er det mulig å holde portstreet oppdatert og motta mail om hva som er utdatert. "portupgrade" kan også hjelpe deg å være oppdatert til en hver tid. Men du må følge litt med på hva du oppdaterer...

Lenke til kommentar

Bruk pakkesystemer hvis tilgjengelig pga. enkel oppdatering av programvare (nye versjoner, bugfixer, sikkerhetsfikser).

 

Kompilerer man et helt system som skal kjøres i "produksjon", får man tilnærmet en fulltidsjobb med å sjekke etter oppdateringer, laste ned, rekompilere og reinstallere. Pakkesystemene/ports inneholder funksjonalitet for å automatisere dette, så det er de som vedlikeholder pakkene for OS-utgivelsen (package maintainer), og ikke DEG som bruker som får denne jobben.

 

Hvis du liker mye ekstrajobb for minimal ekstra fleksibilitet, og påfølgende økt kompleksitet, så for all del.. slå deg løs. Men for de aller aller fleste (dvs, de som skal BRUKE programmene, og ikke de som lager dem, driver utstrakt testing etc), så lønner det seg å la være å kompilere helt selv så langt det lar seg gjøre.

 

Edit: som hamster påpeker, en annen stor fordel er håndteringen av dependencies.

Endret av Sokkalf^
Lenke til kommentar

det er det som er så genialt med ports, det er kontrollert kompilering. Man kan oppdatere, ports passer på dependencies og man har fortsatt fleksibiliteten. Ulempen er at man må kompilere hele tiden og det tar tid.

 

Synes det er rart linux ikke har noe lignende for ports er genialt.

Lenke til kommentar

soo... dere tenker at jeg burde avinstallere apache, mysql og php (som jeg installerte fra tar.gz arkiver) og reinstallere det fra ports. for å avinstallere må jeg finne en "make"-fil som ligger i mappen jeg installete fra og skrive "make uninstall". Så installere alt igjen fra ports. blir ikke den "make"-filen når jeg skriver "make clean". har ikke freebsd et program som kan rese vekk filer som "er gamle" eller ugyldige?

Lenke til kommentar

det er jo derfor vi maser med at å installere fra source sjeldent er lurt. make clean fjerner det som ble generert etter make og make distclean etter make og configure om jeg husker rett. Det du må prøve er make uninstall eller noe lignende (sjekk hjelp og makefila) slik at det avinstalleres noen lunde skikkelig. Og så kan du gå over til ports og legge det inn derfra, og når du gjør det har du plutselig muligheten til å installere og avinstallere som du vil samt oppgradere på en fornuftig måte.

Lenke til kommentar
Synes det er rart linux ikke har noe lignende for ports er genialt.

Vi har pkgsrc ;)

 

Vel, man har jo Gentoo, da.

Emerge (som er pakkesystemet i Gentoo) er etter det jeg har hørt sterkt inspirert av ports.

Emerge lager pakker på samme måten som ports/pkgsrc, men fungerer ikke på samme måte. Den største feature med ports/pkgsrc er at pakkene blir behandlet som en tredjepart, og lever uavhengig av basesystemet.

Endret av olear
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...