[Bug 476600] Review Request: python-ZODB3 - Zope Object Database: Object Database and Persistence

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=476600





--- Comment #7 from Mads Kiilerich <mads at kiilerich.com>  2009-10-29 20:49:31 EDT ---
>> python-BTrees.i586: W: devel-file-in-non-devel-package
>> /usr/lib/python2.6/site-packages/BTrees/_IOBTree.c
>> python-BTrees.i586: E: non-standard-executable-perm
>> /usr/lib/python2.6/site-packages/BTrees/_OIBTree.so 0775
>> python-persistent.i586: W: devel-file-in-non-devel-package
>> /usr/lib/python2.6/site-packages/persistent/cPersistence.h
>> python-ZODB3.i586: W: devel-file-in-non-devel-package
>> /usr/include/python2.6/ZODB3/cPersistence.h
> 
> Yes, after I replied I remembered that I had forgotten to deal with these. My
> next package will simply remove these files from the install, unless you have a
> better suggestion.

I guess that depends on what upstreams purpose with the files is? Are they
installed on purpose or is it an oversight? 

FWIW I can't imagine any reasons why .c files should be included in any
package. Theoretically it could perhaps make sense to expose the C code as a C
library and put the .h files in a -devel package, but I don't think that is
upstreams intention.

>> Have you considered putting sub-modules somewhere else than in the global
>> namespace instead of creating sub-packages? If it was an executable it could be
>> put in /usr/share (like for example rpmlint does), but in this case I guess it
>> could be below /usr/lib/python2.6/site-packages/ZODB? What is upstreams
>> opinion? (My past experience with Zope is that they have their own strong
>> sub-community and don't try that hard to fit into system packaging, but instead
>> recommends building a python from source and not sharing it with anything
>> else.)
> 
> I'm not familiar with this; I think it would involve (at least) modifying all
> the ZODB sources to look for these packages in a different place (or run any
> program using ZODB with a PYTHONPATH including whatever subdirectory we
> choose). 

It _could_ be done in the ZODB module simply by inserting the right path in
sys.path before importing - or by manipulating sys.modules. But I don't know if
I would propose doing it in a Fedora patch.

I think we need input from upstream if they see it as one module or as 4
modules each on their own right. In either case it could be nice if they
distributed it in a way which matched their intention.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.