Re: Conflicting Packages Policy (was: python26 note)
On Mon, 2010-10-18 at 12:30 -0700, Toshio Kuratomi wrote:
On Mon, Oct 18, 2010 at 10:42:08AM -0600, Kevin Fenzi wrote:
>
> So, some more questions I have:
>
> * Would this conflicts case be restricted to just these python26-mod*
> packages? Or is this more general? I can see the case for packages
> that use a parallel installable stack and can't load at the same
> time, but I worry that we should make sure this isn't used more
> broadly.
>
The technical criteria leading to this are:
* Plugins to an app (in this case, mod_{python,wsg} to apache)
* Plugins link to a library that is versioned at the library level but not
versioned/namespaced at the symbol level. (In this case, libpython24.so
and libpython26.so which provide an overlapping set of function names).
Whether to create a general criteria from this or limit it to the specific
case of apache with
mod_python/python26-mod_python/mod_wsgi/python26-mod_wsgi I leave to you :-)
Attempting to dynamically link a single process against both python 2.4
and python 2.6 is likely to make that process crash.
My understanding is that it's possible for an Apache expert (which I am
not) to set up multiple, independent configurations of httpd on a host,
which would run as separate processes.
With that in mind, it seems reasonable to provide pre-built libraries in
RPM form (e.g. to avoid needing to have a compilation toolchain
installed).
So I think that there is a use-case to have both a python2.4 mod_wsgi
and a python 2.6 mod_wsgi installed via RPM - but it's only of use to
someone prepared to do a lot of reconfiguration of httpd; without that,
one needs to have some kind of stern warning in the configuration.
So I'm not convinced that it's correct to "forbid" this at the RPM
level: there are reasonable situations where you might want both RPMs
installed.
Hope this makes sense
Dave