python-devel June 2010

python-devel@lists.fedoraproject.org

4 participants
3 discussions

private-shared-object-provides
by Thomas Spura 29 Jul '10

29 Jul '10

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

1 1

Re: To construct a Zope skyscraper on Fedora
by Nathaniel McCallum 20 Jun '10

20 Jun '10

On 06/20/2010 12:22 AM, Jonathan Steffan wrote: > On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote: >> The 'zope' package itself is most kept under the same conventions of the >> legacy 2.10.x 'zope' package. > > We have a unique opportunity to address many of the failings of the > current zope namespace. We should get anyone interested (and willing to > do the work) into a meeting soon. Every time I go back to building up > zope again I run out of steam and end up just being frustrated. I > foresee issues with splitting out every module in this stack but it just > needs to be discussed. The current package layout is far from optimal > and it's not the best idea to ship a default standalone instance with > the package. Shipping standalone/zeo instance configs/etc. in > subpackages is a far better idea. I've never been able to address this > as there is just about no upgrade path (that I've been able to design) > that would allow for a safe re-layout of the current package. > > We should consider the current "zope" namespace dead and start from > scratch. It's far too complex of an application to be able to have > everything in one namespace (speaking to zope2 vs zope3.) I've only > briefly looked into all of the specs you've worked on and already can > see we are going to run into issues with cross-product dependencies. I > could be convinced that the "zope" namespace should be the latest 2.x > and then address the need for zope 3 in the zope3 namespace. However, > how do we distinguish a module built for zope 2 vs zope 3? This, again, > could be solved but will need discussion. > > With zope 2.12 supporting py2.6, I think we might actually have a shot > at making this work. However, immediately off the bat if we stick 2.12.x > into "zope" what happens to grok? What packages are going to break? Too > many things need zope 2.x so updating the "zope" namespace to zope 3 > would break a lot of good software. What happens to plone? Do we just > ditch Plone 3 and only support Plone 4?[2] > > We could also modularize everything and have things like "zope", > "plone", "grok" and "zenoss" have dependencies based on their release > recipes. There are a lot of common modules in these projects, but they > all have their own specific version requirements. This would be a lot of > work and could potentially cause us to package ourselves into a corner > where we are having to do absolute requires or just end up with broken > software when absolute requirements are not properly documented. > > I really look forward to others being involved with this. Count me in > for the SIG.[2] > > - Jonathan Steffan > > [1] http://plone.org/documentation/faq/plone-versions > [2] http://fedoraproject.org/wiki/SIGs/Zope I agree, we've got lots to talk about. The most important things are: 1. Packaging guidelines 2. Component upgrade guidelines 3. Namespace issues (addressed above) 4. Zope 2 vs Zope 3 (again, addressed above) I think we should talk sooner rather than later. Anyone want to setup a meeting time? Just an FYI, it is my current plan (probably because I am completely ignorant as to how much pain this will cause) is to simply package the latest version of all Zenoss dependencies and then work through whatever bugs I find. I'm in a somewhat unique situation though in that I have the ability to commit to upstream. This may be a less than ideal plan for other applications. As I mentioned to Jonathan on IRC, I think the best plan is to try to get something working'ish as soon as possible and then try to shakedown the details from there. If we bog ourselves down in policy (an easy quagmire to get stuck in when in zopeland) we may get too discouraged to continue. Not to dismiss what will be the very needed policy, I just want to make sure no-one gets burned out. One thing we may want to consider is a "tenant" policy. That is, the zope stack as a whole has "tenants" (Zenoss, Plone, etc). The tenants would be formally defined and any upgrade to any component in the platform would require signoff from all the tenants who depend on that component (or some derivation thereof). I suspect that the short-term trade-off of buildouts/bundling is not as valuable as the long-term value of testing a software product across multiple versions of its dependencies. Nathaniel

2 3

Re: To construct a Zope skyscraper on Fedora
by Rakesh Pandit 19 Jun '10

19 Jun '10

On 18 June 2010 18:38, Robin 'cheese' Lee wrote: > Hello, all! > > And the foundations and first floors of this skyscraper is Zope2 and its > dependencies, which I have built up. The latest version of Zope2 is 2.12.7. > > All the spec files are accessible through my git repo: > http://fedorapeople.org/gitweb?p=cheeselee/public_git/rpm.git;a=tree;h=refs… > > And an yum repo (i686 and SRPM) for F-13 is also available: > http://cheeselee.fedorapeople.org/yum/zope/ > > Steps to make a trivial test: > $ wget http://cheeselee.fedorapeople.org/yum/zope-cheese.repo > $ su -c "cp zope-cheese.repo /etc/yum.repos.d/" > $ su -c "yum install zope" > $ su -c "service zope start" > $ xdg-open http://localhost:8080/ > I don't remember exactly, but wasn't zope a no go in Fedora, and for this matter isn't compat-zope already in rpmfusion (because it needs compat-python24) . Or is this different ? Are you planning to put them in Fedora ? Between may you put x86_64 builds in your repo ? -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel June 2010