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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
