On 07/08/09 23:02, Sriram Natarajan wrote: > Seema > Did we check how it is done on other distribution like Debian (who does We had to support multiple minor releases (for whatever reasons...) and this layout helped us achieve that. Other distros don't do that.
> split these into separate packages) ? I am sure, there will be quite a > number of apache modules - that require some header files from apr and > the rest from apr-util . have a complex configure script (with using > CFLAGS) can be quite a bit of pain. Already, we do make things quite > hard by not keeping these header files under /usr/include - like being > commonly done on other linux distributions.. Generally, the components/moodules which require apr and apr-util, use apr-config and apu-config (and use apxs to get apr-config/apu-config location) to get the install location details. So user doesn't really have to explicitly specify. But suphp doesn't do that; even though it depends on apr-util, it just uses apr-config. -- Seema. >> >> On 07/08/09 08:26, Jyri Virkki wrote: >>> Sriram Natarajan wrote: >>>> extensions like these depend on various apr header files. while some >>>> of them reside within apr while the rest deliver within apr-util >>>> package. now, if we had both apr/apr-util (even if it is a separate >>>> package) deliver its header files under /usr/apr/1.3 , things would >>>> have been lot easier rather what we have now - /usr/apr/1.3 and >>>> /usr/apr-util/1.3 >>> >>> Ah, don't know|remember why the file layout split. Hopefully others >>> can comment what led to it. >> >> The main reason was that apr and apr-util were two different projects >> with >> different release cycles. Hence, the current layout was proposed to >> support >> apr 1.3 and apr-util 1.4 like scenarios ! >> >> >> -- Seema. >> >> >>>> Just to clarify - i am not questioning as to why we split these >>>> packages >>> >>> Re-read your Subject line to see why the confusion ;-) >>> >>> >>>
