private-shared-object-provides
by Thomas Spura
Hi list,
with a recent rpmlint, there will be a new warning
'private-shared-object-provides'. This will always trigger a *.so file
inside of %{python_sitearch} as a wrong dependency:
"""
A shared object soname provides is provided by a file in a path from
which other packages should not directly load shared objects from.
Such shared objects should thus not be depended on and they should not
result in provides in the containing package. Get rid of the provides
if appropriate, for example by filtering it out during build. Note
that in some cases this may require disabling rpmbuild's internal
dependency generator.
"""
Is there a easy way to fix the find-requires script, so this won't be
emitted in next builds? The current workaround is to manually grep away
the unwanted provides, but... it's a workaround.
While viewing the current find-requires script I found the file
'/usr/lib/rpm/python.prov', which apparently doesn't exist yet.
Is this on someone's TODO list? If not, maybe I'll have a look.
Thomas
13 years, 1 month
PyPyStack feature
by David Malcolm
I'm extremely busy with 3 features for Fedora 14, and with other
Python-related activities, and I can't realistically devote much time to
the PyPy feature here:
https://fedoraproject.org/wiki/Features/PyPyStack
Unfortunately, the deadline for Feature submission for F14 was today,
and that page isn't finished yet. I'm sorry for not asking for help
earlier.
If someone else wants to take this and run with it, that would be great.
Otherwise, I hope to do it in Fedora 15.
Dave
13 years, 2 months
Dealing with namespaces
by Robin 'cheese' Lee
Hello!
When packaging Zope packages, I face to multiple namespaces, for
example, 'zope', 'zope.app', 'zc' and 'grokcore'.
When installing a package like 'zope.component' through 'python setup.py
install', the module it provides will go to
%{python_sitelib}/zope/component . If no other zope.* packages
installed, the %{python_sitelib}/zope/ directory will contain only the
'component/' directory. In this case, it will fail to import the
'zope.component' module trivially in Python, because the
%{python_sitelib}/zope/ directory doesn't contain a file named
'__init__.py'. So, we must provide %{python_sitelib}/zope/__init__.py
through some rpm. And the rpm which provides %{python_sitelib}/zope/ and
%{python_sitelib}/zope/__init__.py is called namespace holder rpm.
I propose three candidate solutions:
Candidate 1: per-project namespace holder rpm
This is what I did for Zope2 and Grok in the Zope SIG repo[1].
So I provide two namespace holder rpms: python-zope-filesystem[2] and
python-grok-filesystem[3]. python-zope-filesystem provides all the
namespaces needed by Zope packages and python-grok-filesystem by Grok
packages.
That is, a namespace holder rpm may provides multiple
namespaces needed by that project.
Results of this candidate: Less namespace holder rpms, no .pth
file needed, no mechanical method to decide a namespace contained by
which rpm (see Candidate 2).
Candidate 2(I really prefer): per-toplevel-namespace namespace
holder rpm
For each top-devel namespace, we provide a namespace holder
rpm. For example, the zope and zope.app namespaces will be provided by
an rpm(may named 'python-namespace-zope'), and zc and zc.recipe by
another rpm(may named 'python-namespace-zc').
So we have a mechanical method to decide a namespace contained
by which rpm. For example, given a new package named 'yes.ok.bye', when
packaging it as rpm, it must require 'python-namespace-yes'. And if the
yes.ok namespace is not provided by 'python-namespace-yes', we can just
make a new version of 'python-namespace-yes'. And if
'python-namespace-yes' rpm is not available in Fedora, we can just make
it, and it will definitely conflicts with no other rpms.
Results of this candidate: More namespace holder rpms, no .pth
file needed, can mechanically decide a namespace contained by which rpm.
Candidate 3: No namespace holder rpm, long-name packages are
installed as eggs.
Most long-name packages(like zope.componet, not like paste)
will be packaged as eggs, through
http://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions .
And for each of these packages, a .pth file is used to add new directory
to sys.path.
Results of this candidate: No namespace holder rpm needed,
many .pth files needed and sys.path will turn huge if you install
something like Grok.
Unfortunately, I have to go to field work tomorrow and have no access to
Internet for about a month.
[1]
http://fedorapeople.org/gitweb?p=cheeselee/public_git/zope-rpm.git;a=tree...
[2]$ rpm -ql python-zope-filesystem
/usr/lib/python2.6/site-packages/five
/usr/lib/python2.6/site-packages/five/__init__.py
/usr/lib/python2.6/site-packages/five/__init__.pyc
/usr/lib/python2.6/site-packages/five/__init__.pyo
/usr/lib/python2.6/site-packages/z3c
/usr/lib/python2.6/site-packages/z3c/__init__.py
/usr/lib/python2.6/site-packages/z3c/__init__.pyc
/usr/lib/python2.6/site-packages/z3c/__init__.pyo
/usr/lib/python2.6/site-packages/z3c/recipe
/usr/lib/python2.6/site-packages/z3c/recipe/__init__.py
/usr/lib/python2.6/site-packages/z3c/recipe/__init__.pyc
/usr/lib/python2.6/site-packages/z3c/recipe/__init__.pyo
/usr/lib/python2.6/site-packages/zc
/usr/lib/python2.6/site-packages/zc/__init__.py
/usr/lib/python2.6/site-packages/zc/__init__.pyc
/usr/lib/python2.6/site-packages/zc/__init__.pyo
/usr/lib/python2.6/site-packages/zc/recipe
/usr/lib/python2.6/site-packages/zc/recipe/__init__.py
/usr/lib/python2.6/site-packages/zc/recipe/__init__.pyc
/usr/lib/python2.6/site-packages/zc/recipe/__init__.pyo
/usr/lib/python2.6/site-packages/zope
/usr/lib/python2.6/site-packages/zope/__init__.py
/usr/lib/python2.6/site-packages/zope/__init__.pyc
/usr/lib/python2.6/site-packages/zope/__init__.pyo
/usr/lib/python2.6/site-packages/zope/app
/usr/lib/python2.6/site-packages/zope/app/__init__.py
/usr/lib/python2.6/site-packages/zope/app/__init__.pyc
/usr/lib/python2.6/site-packages/zope/app/__init__.pyo
[3] $ rpm -ql python-grok-filesystem
/usr/lib/python2.6/site-packages/grokcore
/usr/lib/python2.6/site-packages/grokcore/__init__.py
/usr/lib/python2.6/site-packages/grokcore/__init__.pyc
/usr/lib/python2.6/site-packages/grokcore/__init__.pyo
/usr/lib/python2.6/site-packages/grokui
/usr/lib/python2.6/site-packages/grokui/__init__.py
/usr/lib/python2.6/site-packages/grokui/__init__.pyc
/usr/lib/python2.6/site-packages/grokui/__init__.pyo
/usr/lib/python2.6/site-packages/megrok
/usr/lib/python2.6/site-packages/megrok/__init__.py
/usr/lib/python2.6/site-packages/megrok/__init__.pyc
/usr/lib/python2.6/site-packages/megrok/__init__.pyo
Robin 'cheese' Lee
13 years, 2 months
About Zope SIG mailing list and progress report
by Robin 'cheese' Lee
Sorry for my late joining.
A Zope specific mailing list may not be in urgent need by now. We can
just use this mailing list, which is for Python packaging in general.
The traffic of this mailing list is low and some of our decisions for
Zope packagine may affect wider Python packaging practices.
Gentoo has excellent support for Zope packages.
http://packages.gentoo.org/package/net-zopeb/zope?arches=linux .
And because Gentoo supports multiple versions of a package, the
maintainability of Zope packages in Gentoo seems more rigorous.
I am now working on Grok and should finish in days.
We should not package Zope3, instead we may aim at BlueBream directly,
which is in beta now.
I am also waiting for Plone 4, which is in beta too.
And I am still considering a Fedora enhancement for
distribute(setuptools) and distutils.
Robin
13 years, 2 months