[Ubuntu] SVN/ssl Compile error

[Verwijderd]

Hallo.

Zojuist ben ik SVN op mijn server aan het installeren om te kunnen werken met ssl. Ik gebruik ubuntu feisty fawn.

En ik gebruik de volgende configuratie regel:

'./configure' \
'--with-ssl' \
'--sysconfdir=/etc' \
'--with-apxs=/usr/local/apache2/bin/apxs' \
'--with-libs=/usr/local' \
'--mandir=/usr/share/man' \
'--with-apr=/usr/local/apr' \
'--with-apr-util=/usr/local/apr' \
'--with-berkeley-db=/usr' \
'CFLAGS= -I/usr/local/ssl/include/openssl -ldl' \
'LDFLAGS= -L/usr/local/ssl/lib -lssl -lcrypto' "$@"

Het is de bedoeling dat ik svn met apache via https laat werken. Maar tijdens het configureren krijg ik de volgende error:

checking openssl/ssl.h usability... no
checking openssl/ssl.h presence... no
checking for openssl/ssl.h... no
configure: error: OpenSSL headers not found, cannot enable SSL support
configure failed for neon

De melding geeft aan dat hij de headers niet kan vinden. Echter.. in /usr/local/ssl/include/openssl staan alle header files van Openssl, en ook het ssl.h bestand.

De LDFLAGS en CFLAGS zijn nodig omdat ik openssl met een ietwat omweg heb geinstalleerd (ivm een verouderde versie van apt-get) dus moet ik deze apart aan geven.

Heeft iemand een idee hoe ik dit zou kunnen verhelpen?

[moto-moi]

Ehm, redelijk offtopic: waarom compileer je dit zelf als er al gewoon svn in ubuntu zit?

hylke@kahlan:/proc$ apt-cache search svn
[..]
libapache2-svn - Subversion server modules for Apache

Verder, als je het perse zelf wilt compileren, je mist zo te zien openssl-dev, al zou ik je echt aan willen raden om het via je package manager op te lossen, want dit soort dingen zijn echt knap waardeloos om zelf te onderhouden.

[Verwijderd]

Maar kun jij mij dan uitleggen waarom in ubuntu feisty fawn (als je apt-get gebruikt) een openssl versie van september 2006 zit?

Dat lijkt mij behoorlijk verouderd? Dat is de eigenlijke reden dat ik (openssl en svn) zelf compileer....

Edit: Of beter gezegd (gevraagd), Waarom is het dan geen probleem om een openssl versie uit september 2006 te gebruiken. Ik bedoel, de makers van openssl (en niet alleen openssl) brengen toch niet voor niets nieuwe versies uit....

Edit2: Ik heb het nu over openssl, maar dat is eigenlijk hetzelfde als met svn.. de oude versies..

[ Voor 43% gewijzigd door Verwijderd op 07-12-2007 21:47 ]

[deadinspace]

Verwijderd schreef op vrijdag 07 december 2007 @ 21:27:
Of beter gezegd (gevraagd), Waarom is het dan geen probleem om een openssl versie uit september 2006 te gebruiken. Ik bedoel, de makers van openssl (en niet alleen openssl) brengen toch niet voor niets nieuwe versies uit....

Ik heb het nu over openssl, maar dat is eigenlijk hetzelfde als met svn.. de oude versies..

Zitten er in nieuwere versies van libssl en svn dan features die je perse nodig hebt ofzo? Zou je het (zonder naar de versienummers te kijken) uberhaupt wel merken dat het niet de meest recente versies zijn?

Voor security problemen zijn er gewoon security updates. Wat erger is, voor een zelfgecompilede libssl en svn krijg je geen security updates, dus die moet je weer zelf met het handje gaan lopen compilen (als je daar uberhaupt al aan denkt), dus door nu de laatste versies zelf te compilen haal je je op langere termijn meer security problemen op de hals.

En als laatste... Als die oude versies je zo storen, waarom gebruik je dan Feisty?

[Verwijderd]

Als oude stabiele versies je storen, dan moet je geen Ubuntu gebruiken, maar Debian Unstable. Die zal altijd zo snel mogelijk nieuwe versies van programma's beschikbaar maken.

[Verwijderd]

deadinspace schreef op zaterdag 08 december 2007 @ 01:13:
[...]

Zitten er in nieuwere versies van libssl en svn dan features die je perse nodig hebt ofzo? Zou je het (zonder naar de versienummers te kijken) uberhaupt wel merken dat het niet de meest recente versies zijn?

Nou, die versie nummers interesseren me op zich niet.. maar het zit mijn vooral in het feit dat ik bang was voor security problemen.

Voor security problemen zijn er gewoon security updates. Wat erger is, voor een zelfgecompilede libssl en svn krijg je geen security updates, dus die moet je weer zelf met het handje gaan lopen compilen (als je daar uberhaupt al aan denkt), dus door nu de laatste versies zelf te compilen haal je je op langere termijn meer security problemen op de hals.

Zo had ik het nog niet bekeken. Maar ik werd verward door het feit dat er op de pagina van feisty's openssl package staat: versie 0.9.8c. En als ik dan keek op de site van openssl, dan zie ik dat die uit september 2006 stamt. Maar ik wist niet dat daar dan wel de security fixes in gemaakt zijn.

En als laatste... Als die oude versies je zo storen, waarom gebruik je dan Feisty?

Dat blijkt dus op een misverstand te berusten. Die versies storen me niet, maar de bugs enzo (maar dat blijkt dus wél verholpen te worden)

Ik heb nog wel een aantal vraagjes, waar ik van hoop dat iemand antwoord kan geven:

1. Stel dat ik bij SVN de configure optie '--with-ssl' nodig heb, zit dit dan ook in de apt-get veriant? Of hoe kan ik ervoor zorgen dat dit erbij zit..
2. Stel.. ik installeer bijvoorbeeld apache met apt-get. En twee weken later komt er een nieuwe versie uit, en daar zitten nieuwe features in, zal dit dan ook updatebaar zijn met apt-get? Of worden er dan alleen security fixes toegepast?
3. Stel dat ik apache met apt-get heb geinstalleerd, hoe zit het dan met php? Ik heb daar bijvoorbeeld een hele lijst configure parameters, die ik allemaal handmatig instel en zo. Zou ik dit dan via apt-get kunnen doen (hoe weet ik dan zeker dat al die modules van php ook echt meegeinstalleerd worden)? Of kan ik dit gewoon handmatig blijven compileren, want dat lijkt me toch het fijnste bij php..? (En php is dan gewoon een voorbeeld, maar het gaat mij eigenlijk om zo'n ingenesteld programma als php bij apache is)

[Verwijderd]

Pakketten van Apt zijn gecompileerd met sane defaults. Die kan je niet veranderen. Voor de php-module van Apache is een apart pakketje in de Apt-repositories. Wat maakt compileren fijn? Ben je een masochist?

En functionele updates komen niet in de repositories. Elke 6 maanden komt er een nieuwe release uit van Ubuntu, waarin alle versies gebumpt worden. Als Firefox 3 toevallig net 2 weken daarna uitkomt, dan zal die pas na 5 maanden en 2 weken in de repositories terecht komen.

Soms wordt er een pakketje ge-"backport" vanuit de development-tak van Ubuntu. Zo'n pakket moet dan geen nieuwe versies van libs nodig hebben. Om dat soort functionele updates te krijgen moet je de backport-repository aanvinken.

Maar als je geen halfjaarlijkse updates wilt kan je beter Debian Unstable / Gentoo gebruiken.

Heb je trouwens door dat Feisty Fawn een functioneel outdated systeem is? Er worden nog wel security-fixes op gedaan, maar er is alweer een nieuwe functionele versie genaamd Gutsy Gibbon.

[ Voor 10% gewijzigd door Verwijderd op 08-12-2007 04:26 ]

[deadinspace]

Verwijderd schreef op zaterdag 08 december 2007 @ 02:16:
Zo had ik het nog niet bekeken. Maar ik werd verward door het feit dat er op de pagina van feisty's openssl package staat: versie 0.9.8c. En als ik dan keek op de site van openssl, dan zie ik dat die uit september 2006 stamt.

Waar kijk jij dan? Als ik naar Feisty's openssl pagina kijk, dan zie ik:

openssl (0.9.8c-4ubuntu0.2) [security]

En op de Changelog pagina (ook te vinden in /usr/share/doc/openssl/changelog.Debian.gz) staat gewoon wat er veranderd is in -4ubuntu0.2, waaronder een security fix dus.

Kijk eens rond op de Ubuntu site en in hun documentatie, want dit is op zich wel te vinden (al moet ik zeggen dat ze het bij Ubuntu beter weggestopt hebben dan bij Debian).

Stel dat ik bij SVN de configure optie '--with-ssl' nodig heb, zit dit dan ook in de apt-get veriant? Of hoe kan ik ervoor zorgen dat dit erbij zit..

Daarvoor moet je kijken naar de package description, de depends en/of de documentatie van het package. Soms zijn er meerdere packages van hetzelfde programma beschikbaar.

Een betere vraag is of je --with-ssl uberhaupt wel nodig hebt... Als je svn via apache benaderbaar maakt, dan is het volgensmij apache die ssl doet, niet svn.

Stel.. ik installeer bijvoorbeeld apache met apt-get. En twee weken later komt er een nieuwe versie uit, en daar zitten nieuwe features in, zal dit dan ook updatebaar zijn met apt-get?

Niet voor Ubuntu of Debian stable releases.

Stel dat ik apache met apt-get heb geinstalleerd, hoe zit het dan met php? Ik heb daar bijvoorbeeld een hele lijst configure parameters, die ik allemaal handmatig instel en zo.

De vraag is... Waarom?

Zou ik dit dan via apt-get kunnen doen

Nee. De packages zijn gebuild met bepaalde opties, die kun je naderhand niet meer wijzigen.

(hoe weet ik dan zeker dat al die modules van php ook echt meegeinstalleerd worden)

Huh? Je installeert bepaalde php packages, en die bevatten bepaalde modules. Dan zijn die modules toch geinstalleerd?

Of kan ik dit gewoon handmatig blijven compileren, want dat lijkt me toch het fijnste bij php..? (En php is dan gewoon een voorbeeld, maar het gaat mij eigenlijk om zo'n ingenesteld programma als php bij apache is)

Alles kan, maar zo fijn lijkt het mij niet

En hoezo is php "ingenesteld" bij Apache? Het is (mede te gebruiken als) een apache module, en zo'n ingewikkelde interactie is dat niet. Apache komt een php file tegen, vraagt php om die te interpreteren, en served de output daarvan. Ik snap niet goed waarom dat magischerwijs zelf gecompiled zou moeten worden...

edit:

Hou je trouwens voor al die zelfgecompilede dingen de security-meldingen bij? Controleer je regelmatig of er een nieuwe apache is, en compile je die opnieuw als er een nieuwe versie met security fixes is?

[ Voor 3% gewijzigd door deadinspace op 08-12-2007 15:51 ]

[Verwijderd]

@DOT:

Pakketten van Apt zijn gecompileerd met sane defaults. Die kan je niet veranderen. Voor de php-module van Apache is een apart pakketje in de Apt-repositories.

Maar wat dan als ik bijvoorbeeld svn met apt-get installeer, en ik heb openssl nodig. Maar dit zit niet in de versie van apt-get, dan móet ik het toch wel zelf compileren?

Wat maakt compileren fijn? Ben je een masochist?

Dat ik zelf kan instellen wat ik bijvoorbeeld bij SVN kan installeren.

Heb je trouwens door dat Feisty Fawn een functioneel outdated systeem is? Er worden nog wel security-fixes op gedaan, maar er is alweer een nieuwe functionele versie genaamd Gutsy Gibbon.

Oke.. dan zal ik deze een dezer dagen eens installeren, dan kan ik mooi deze feisty fawn installatie even als 'speeltuin' gebruiken om mee te testen met apt-get


@deadinspace:

Daarvoor moet je kijken naar de package description, de depends en/of de documentatie van het package. Soms zijn er meerdere packages van hetzelfde programma beschikbaar.

Voor zover ik kan zien staat nergens in de package description vam SVN, dat er openssl-support enabled is.

Een betere vraag is of je --with-ssl uberhaupt wel nodig hebt... Als je svn via apache benaderbaar maakt, dan is het volgensmij apache die ssl doet, niet svn.

In de helpfile van de configure van SVN staat het volgende:

  
--with-ssl              This option does NOT affect the Subversion build
                          process in any way. It enables OpenSSL support in
                          the Neon library. If and only if you are building
                          Neon as an integrated part of the Subversion build
                          process, rather than linking to an already installed
                          version of Neon, you probably want to pass this
                          option so that Neon (and so indirectly, Subversion)
                          will be capable of https:// access.

En dat is precies wat ik wil bereiken, ik wil svn via https bereikbaar maken.

Nee. De packages zijn gebuild met bepaalde opties, die kun je naderhand niet meer wijzigen.

Maar wat heb ik er dan aan. Als ik php normaalgesproken zou configureren met de onder andere de optie:

'--with-pgsql=/usr/local/pgsql' 

Hoe kan ik dan zorgen dat ik dezelfde functionaliteit heb met een apt-get variant van php, die ik heb wanneer ik zelf php configureer met de '--with-pgsql=/usr/local/pgsql' optie. Is dit toe te voegen met een losse php package? Of gebeurt dit automatisch?

Alles kan, maar zo fijn lijkt het mij niet

En hoezo is php "ingenesteld" bij Apache? Het is (mede te gebruiken als) een apache module, en zo'n ingewikkelde interactie is dat niet. Apache komt een php file tegen, vraagt php om die te interpreteren, en served de output daarvan. Ik snap niet goed waarom dat magischerwijs zelf gecompiled zou moeten worden...

Met die vraag bedoelde ik meer dit:

Is het dan ook mogelijk om apache met apt-get te installeren, en dan php handmatig te compileren (dus niet met apt-get)? (Php zou ik dan zelf installeren om ervoor te zorgen dat ik die opties heb.. zoals pgsql/mysql en dat soort dingen).
Dus anders gevraagd, maakt het uit of ik het ene wel met apt-get doe, en het andere niet...

Hou je trouwens voor al die zelfgecompilede dingen de security-meldingen bij? Controleer je regelmatig of er een nieuwe apache is, en compile je die opnieuw als er een nieuwe versie met security fixes is?

Ja zoiets, dan updatede ik eens in de zoveel tijd de hele bende..

[ Voor 8% gewijzigd door Verwijderd op 08-12-2007 19:52 ]

[icyx]

Dit is een interessante discussie moet ik zeggen, maar ik vraag me heel de tijd al iets af. Waarom gebruik je (sander dus ) geen gentoo? Daar kan je natuurlijk gewoon in je make.conf alles aangeven wat je wel en niet wil, en dat met alle packages die je wilt hebben.

[Verwijderd]

Volgens mij heeft Apt tegenwoordig ook een soort van make.conf, waarmee je dan met apt-build source (of zoiets) je eigen pakketjes kan compileren. Het is alleen niet zo uitgebreid als Gentoo natuurlijk. Met Ubuntu geef je de controle toch enigszins uit handen aan de package maintainers. Gentoo lijkt me een betere keuze als je alles zelf in de hand wilt houden. Het maakt het gemakkelijk om van source te compilen, en toch dingen als dependencies en updates niet handmatig uit te hoeven zoeken.

Ik ben persoonlijk niet zo'n controle-freak. Ik ben nog nooit tegengekomen dat ik een pakket met andere opties had willen compileren. Je komt weleens een pakket tegen waarvan je de oude versie niet kan gebruiken. Denk aan Wine, of aan libOgre (graphics engine). Daarbij haal ik in het geval van Wine gewoon de pakketjes van WineHQ binnen, en Ogre compileer ik -bij gebrek aan specifiek Ubuntu-pakketje- zelf.

[Verwijderd]

Nu heb ik zojuist getracht subversion te installeren via apt-get. Dat werkt in principe goed.. Maar nu heb ik wel een concreet voorbeeld van wat mijn probleem is.

Ik wilde namelijk de optie '--with-apxs' hebben. Maar dit krijg ik dus voor geen mogelijkheid voor elkaar met apt-get. Ik wil dus de mod_dav_svn hebben, in apache, maar die krijg ik nu niet met apt-get. Heeft iemand hier misschien een oplossing voor? Zoeken naar mod_dav_svn of mod_svn op ubuntu's packages pagina

icyx schreef op zaterdag 08 december 2007 @ 20:01:
Dit is een interessante discussie moet ik zeggen, maar ik vraag me heel de tijd al iets af. Waarom gebruik je (sander dus ) geen gentoo? Daar kan je natuurlijk gewoon in je make.conf alles aangeven wat je wel en niet wil, en dat met alle packages die je wilt hebben.

Bedankt voor de tip.. ik ga er zeker eens over nadenken en uitzoeken hoe dat precies werkt...

Verwijderd schreef op zaterdag 08 december 2007 @ 21:21:
Volgens mij heeft Apt tegenwoordig ook een soort van make.conf, waarmee je dan met apt-build source (of zoiets) je eigen pakketjes kan compileren. Het is alleen niet zo uitgebreid als Gentoo natuurlijk. Met Ubuntu geef je de controle toch enigszins uit handen aan de package maintainers. Gentoo lijkt me een betere keuze als je alles zelf in de hand wilt houden. Het maakt het gemakkelijk om van source te compilen, en toch dingen als dependencies en updates niet handmatig uit te hoeven zoeken.

Klinkt ideaal!!

Verwijderd schreef op zaterdag 08 december 2007 @ 21:21:
Ik ben persoonlijk niet zo'n controle-freak. Ik ben nog nooit tegengekomen dat ik een pakket met andere opties had willen compileren. Je komt weleens een pakket tegen waarvan je de oude versie niet kan gebruiken. Denk aan Wine, of aan libOgre (graphics engine). Daarbij haal ik in het geval van Wine gewoon de pakketjes van WineHQ binnen, en Ogre compileer ik -bij gebrek aan specifiek Ubuntu-pakketje- zelf.

Ik vind dat net zoiets als bij wanneer ik bij Windows iets installeert, en er zit ineens een toolbar bij, of er zit een één of ander context menu regeltje bij;

Dat wil ik gewoon zelf bepalen, en niet afhankelijk zijn van die package maintainers.

Maargoed, hoop dat iemand me nog wat kan helpen met dat eerst genoemde probleem in dit bericht. Ik krijg het gewoon niet voor elkaar....

[Gotiniens]

Verwijderd schreef op zaterdag 08 december 2007 @ 23:08:
Nu heb ik zojuist getracht subversion te installeren via apt-get. Dat werkt in principe goed.. Maar nu heb ik wel een concreet voorbeeld van wat mijn probleem is.

Ik wilde namelijk de optie '--with-apxs' hebben. Maar dit krijg ik dus voor geen mogelijkheid voor elkaar met apt-get. Ik wil dus de mod_dav_svn hebben, in apache, maar die krijg ik nu niet met apt-get. Heeft iemand hier misschien een oplossing voor? Zoeken naar mod_dav_svn of mod_svn op ubuntu's packages pagina

sudo apt-get install libapache2-svn

Zoeken in synaptic op "apache svn" was genoeg om je gewenste module te vinden

de ubuntu package search site kon ik het niet op vinden met die 2 woorden vreemd genoeg

[deadinspace]

Verwijderd schreef op zaterdag 08 december 2007 @ 19:51:
@DOT:
Maar wat dan als ik bijvoorbeeld svn met apt-get installeer, en ik heb openssl nodig. Maar dit zit niet in de versie van apt-get, dan móet ik het toch wel zelf compileren?

Als de packages op geen enkele manier de feature bieden die je nodig hebt wel ja. Maar dat is echt knap zeldzaam, want meestal ben je niet de enige die die feature wil, en is die feature daarom beschikbaar (al dan niet via een alternatief package).

In de helpfile van de configure van SVN staat het volgende:

  
--with-ssl              This option does NOT affect the Subversion build
                          process in any way. It enables OpenSSL support in
                          the Neon library. If and only if you are building
                          Neon as an integrated part of the Subversion build
                          process, rather than linking to an already installed
                          version of Neon, you probably want to pass this
                          option so that Neon (and so indirectly, Subversion)
                          will be capable of https:// access.

En dat is precies wat ik wil bereiken, ik wil svn via https bereikbaar maken.

Ah, ok, de SSL certs enzo worden idd niet door apache gedaan blijkbaar. Magoed, blijkbaar gebruikt svn daar een library genaamd Neon voor, dus...

$ apt-cache search neon openssl
libneon25 - An HTTP and WebDAV client library
libneon26 - An HTTP and WebDAV client library
$ apt-cache show libneon25 | grep -i openssl
   * SSL/TLS support using OpenSSL (including client certificate support)

Maar wat heb ik er dan aan. Als ik php normaalgesproken zou configureren met de onder andere de optie:

'--with-pgsql=/usr/local/pgsql' 

Hoe kan ik dan zorgen dat ik dezelfde functionaliteit heb met een apt-get variant van php, die ik heb wanneer ik zelf php configureer met de '--with-pgsql=/usr/local/pgsql' optie. Is dit toe te voegen met een losse php package? Of gebeurt dit automatisch?

Mja, kijk ook zelf eens in de package lists

$ apt-cache search php5 pgsql
php5-pgsql - PostgreSQL module for php5

Doe maar eens het volgende om te kijken welke php5 modules er zijn:

$ apt-cache search php | egrep '^php5'

Overigens zal dat waarschijnlijk niet zomaar werken als je postgres in /usr/local staat, maar ook dat is dan weer niet nodig om dezelfde redenen

En dan nog, als je om de een of andere reden zelf postgres moet compilen, dan kun je er een .deb van maken, die installeert in /usr, en dan werkt het wel met php5-pgsql. Los daarvan is php5-pgsql misschien ook nog wel zo in te stellen dat het werkt met postgres in /usr/local.

Is het dan ook mogelijk om apache met apt-get te installeren, en dan php handmatig te compileren (dus niet met apt-get)?

Mogelijk, hangt er vanaf hoe (zie mijn opmerkingen over postgres zelf compilen boven).

Php zou ik dan zelf installeren om ervoor te zorgen dat ik die opties heb.. zoals pgsql/mysql en dat soort dingen

Dat is dus niet nodig, zie boven.

Verwijderd schreef op zaterdag 08 december 2007 @ 21:21:
Volgens mij heeft Apt tegenwoordig ook een soort van make.conf, waarmee je dan met apt-build source (of zoiets) je eigen pakketjes kan compileren.

Ik ken apt-build niet (als ik Debian packages zelf compile, dan doe ik dat meestal met apt-get source). Kan die ook rekening houden met (security) updates, en dan automatisch de gewenste packages opnieuw builden, of blijft dat een handmatige actie?

Verwijderd schreef op zaterdag 08 december 2007 @ 23:08:
Nu heb ik zojuist getracht subversion te installeren via apt-get. Dat werkt in principe goed.. Maar nu heb ik wel een concreet voorbeeld van wat mijn probleem is.

Ik wilde namelijk de optie '--with-apxs' hebben. Maar dit krijg ik dus voor geen mogelijkheid voor elkaar met apt-get. Ik wil dus de mod_dav_svn hebben, in apache, maar die krijg ik nu niet met apt-get. Heeft iemand hier misschien een oplossing voor? Zoeken naar mod_dav_svn of mod_svn op ubuntu's packages pagina

Ubuntu's package search choked op meerdere keywords
Opnieuw, apt-cache to the rescue:

$ apt-cache search svn dav
libapache2-svn - Subversion server modules for Apache
$ apt-cache show libapache2-svn | egrep -A4 '^Description'
Description: Subversion server modules for Apache
 This package provides the mod_dav_svn and mod_authz_svn modules for
 the Apache 2.2 web server.  These modules provide Subversion's WebDAV
 server backend, to serve repositories over the http and https
 protocols.  See the 'subversion' package for more information.

Hoe denk je eigenlijk dat andere mensen dat doen? PHP met postgres of mysql support is doodnormaal, en svn over https komt vast ook regelmatig voor. Denk je dat alle mensen die dat willen die software zelf gaan compilen?

Ik vind dat net zoiets als bij wanneer ik bij Windows iets installeert, en er zit ineens een toolbar bij, of er zit een één of ander context menu regeltje bij;

Dat wil ik gewoon zelf bepalen, en niet afhankelijk zijn van die package maintainers.

En daarom zijn er dus verschillende varianten van bepaalde packages, om je die keuzes te bieden. Verder zijn programma's ook nog instelbaar, waardoor je aan/uit kan zetten wat je wil.

[Verwijderd]

deadinspace schreef op zondag 09 december 2007 @ 00:58:
Ik ken apt-build niet (als ik Debian packages zelf compile, dan doe ik dat meestal met apt-get source). Kan die ook rekening houden met (security) updates, en dan automatisch de gewenste packages opnieuw builden, of blijft dat een handmatige actie?

Ik heb zowel apt-build als apt-get source nooit gebruikt, maar hier staat wat info over apt-build: http://julien.danjou.info/article-apt-build.html

Als ik het goed lees kan je wat machine-specifieke compile-options meegeven voor betere performance, maar ./configure-opties niet:

Now, Gentoo fans will ask me "what about flags ?" ; sorry for us, but there are not. By flags, Gentoo users mean libraries with which software are linked to. Here, it is out of the question for a simple user to change package dependancies.

Je zou naar Pbuilder kunnen kijken. Dat gebruiken de Debian/Ubuntu-developers zelf om officiële pakketten te bouwen. Die hele Packaging Guide is eigenlijk wel eens leuk om door te lezen.

[ Voor 5% gewijzigd door Verwijderd op 09-12-2007 02:30 ]

[Verwijderd]

Late reactie, maar ik was even afwezig .

Ik heb het inmiddels aan het werk gekregen door gewoon de subversion uit apt-get te nemen. Dit werkt op zich wel goed. Die Packaging Guide ga ik zeker eens doorlezen!

Hoe denk je eigenlijk dat andere mensen dat doen? PHP met postgres of mysql support is doodnormaal, en svn over https komt vast ook regelmatig voor. Denk je dat alle mensen die dat willen die software zelf gaan compilen?

Ik zal wel altijd php blijven compileren, want de laatste versie van php bevat altijd wel wat nieuwe functies.. dus ja, die zitten dan niet in apt-get..

[Verwijderd]

Mooi dat het opgelost is! En foei dat wij zo off-topic bezig waren...

En om daar maar meteen weer mee door te gaan... Je zal met het zelf compileren van PHP niet de fixes hebben die Debian erin stopt. Het versie-niveau van Debian Unstable zit op 5.2.4-2. Die "-2" geeft aan dat Debian al 2 eigen releases heeft gedaan met eigen bugfixes die je niet hebt als je zelf vanilla-PHP compileert. Nou heeft PHP zelf alweer een paar fixes in de vorm van 5.2.5 de deur uit gedaan, dus met de Debian-way zal je die fixes weer missen. Kortom, je mist altijd iets! (hoewel je natuurlijk kan verwachten dat een dezer dagen Debian met 5.2.5-1 komt)