Hello,
the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples.
So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB).
The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package.
Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame.
On Tue, Sep 29, 2009 at 2:33 AM, Bernie Innocenti bernie@codewiz.org wrote:
Hello,
the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples.
So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB).
The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package.
Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame.
The numpy dep issue was discussed on fedora-devel a while ago and I thought they were going to split the specific bit of numpy that depended on atlas et al out into a separate package. I was of the understanding that this had already been done.
Peter
On 09/29/2009 12:51 AM, Peter Robinson wrote:
On Tue, Sep 29, 2009 at 2:33 AM, Bernie Innocenti bernie@codewiz.org wrote:
Hello,
the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples.
So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB).
The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package.
Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame.
The numpy dep issue was discussed on fedora-devel a while ago and I thought they were going to split the specific bit of numpy that depended on atlas et al out into a separate package. I was of the understanding that this had already been done.
I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function.
-Toshio
On Tue, Sep 29, 2009 at 9:45 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On 09/29/2009 12:51 AM, Peter Robinson wrote:
On Tue, Sep 29, 2009 at 2:33 AM, Bernie Innocenti bernie@codewiz.org wrote:
Hello,
the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples.
So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB).
The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package.
Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame.
The numpy dep issue was discussed on fedora-devel a while ago and I thought they were going to split the specific bit of numpy that depended on atlas et al out into a separate package. I was of the understanding that this had already been done.
I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function.
I remember that as well but at least with a quick repoquery (I might have got it wrong) it looks like the dependency is still there. Not sure what happened to the fix.
Peter
On 09/29/2009 01:52 PM, Peter Robinson wrote:
On Tue, Sep 29, 2009 at 9:45 PM, Toshio Kuratomi a.badger@gmail.com wrote:
I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function.
I remember that as well but at least with a quick repoquery (I might have got it wrong) it looks like the dependency is still there. Not sure what happened to the fix.
Was that on F-11 or rawhide? I downloaded the pygtk2 package from rawhide and it looks fixed.
-Toshio
On Tue, Sep 29, 2009 at 10:02 PM, Toshio Kuratomi a.badger@gmail.com wrote:
On 09/29/2009 01:52 PM, Peter Robinson wrote:
On Tue, Sep 29, 2009 at 9:45 PM, Toshio Kuratomi a.badger@gmail.com wrote:
I admit I'm not following sugar and numpy discussions too closely so I might have missed it but I don't remember this. I do remember talking about removing the numpy dependency from pygtk because it dragged in atlas, et al and was only used by a single pygtk function.
I remember that as well but at least with a quick repoquery (I might have got it wrong) it looks like the dependency is still there. Not sure what happened to the fix.
Was that on F-11 or rawhide? I downloaded the pygtk2 package from rawhide and it looks fixed.
rawhide, I think the numpy support was just dropped from pygtk2 as opposed to fixing the dependencies in numpy themselves. numpy still depends on atlas and various other stuff. I'm not sure what the impact of either changes are, I'd have to dig back through archives to find the thread.
Peter
On 09/29/2009 02:11 PM, Peter Robinson wrote:
rawhide, I think the numpy support was just dropped from pygtk2 as opposed to fixing the dependencies in numpy themselves. numpy still depends on atlas and various other stuff. I'm not sure what the impact of either changes are, I'd have to dig back through archives to find the thread.
Yep, this is what I remember the outcome of the thread being.
-Toshio