compat-python, Zope...

[Hans de Goede]

James Antill wrote:
> On Wed, 2008-10-15 at 09:08 +0200, Oliver Falk wrote:
>> James Antill wrote:
>> [ ... ]
>>>> I can think of a Python 2.4 package that lives within the Zope tree to 
>>>> make it extra hard for others to use it by accident - but I don't think 
>>>> that this would be neat, seen from a FHS point of view.
>>>  In some ways this might be doable, at least it has less pain points
>>> than packaging it "properly".
>> I'm not sure what you mean here? Do you mean with properly an 
>> /usr/%{_lib}/python%{major}.{minor}/ installation? Well, I'd like to 
>> invite everybody to have a look at the livna packages. Those are fine 
>> and don't hurt the main python...
> 
> % repoquery --repoid=livna --provides compat-python24-imaging      
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)
> compat-python24-imaging = 1.1.6-1.lvn9
> % repoquery --provides python-imaging               
> _imaging.so()(64bit)
> _imagingft.so()(64bit)
> _imagingmath.so()(64bit)

Yes rpmbuild is very broken in that it generates provides for .so files which 
are not under libdir, so plugins for applications / libs / languages can have 
conflicting Provides, luckily nothing should ever Require these plugins. Never 
the less this is an rpm big, which should get fixed for the reduce the repo 
metadata size reason alone, feel free to file a bug *against rpm* for this (or 
add comments to the existing one)

> python-imaging = 1.1.6-9.fc9

Notice how this one differs, and this is the only one which packages should 
ever require!

> % repoquery --repoid=livna --provides compat-python24-lxml   
> compat-python24-lxml = 2.0.5-1.lvn9
> etree.so()(64bit)
> objectify.so()(64bit)
> pyclasslookup.so()(64bit)
> % repoquery --provides python-lxml
> etree.so()(64bit)
> objectify.so()(64bit)
> pyclasslookup.so()(64bit)
> python-lxml = 2.0.8-1.fc9
> 

Same here.

> ...those are all "wrong", in that you can get cross python/python24
> provides/requires.

Yes just like any application which can use esd for sound, but does not has it 
hard compiled in and has a plugin called esd.so for that under %{_libdir}/%{name}

Will conflict with another application which has a plugin with the same name, 
under:
%{_libdir}/%{different-name}

This is an *rpm bug* and I'm sure we already have many many Provides 
"conflicts" becase of this, nothing to see here (except an *rpm bug*) move along.

Regards,

Hans