Conflicting Packages Policy (was: python26 note)

[David Malcolm]

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