On Feb 11, 2011, at 05:18 PM, Jouni K. Seppänen wrote: >[Crossposting to matplotlib devel list] > >Robert Kern <robert.k...@gmail.com> writes: > >> On Thu, Feb 10, 2011 at 11:22, Barry Warsaw <ba...@python.org> wrote: >> >>> Here's the problem: for Ubuntu, we've had to disable the building of >>> the numpy documentation package, because its dependencies violate >>> Ubuntu policy. Numpy is in our "main" archive but the documentation >>> depends on python-matplotlib, which lives in our "universe" >>> archive. Such cross archive dependencies break the build. >>> >>> We can't put python-matplotlib in main because of *its* dependencies. >> >> As a digression, I think the python-matplotlib dependencies could be >> significantly reduced. For a number of use cases (this is one of them, >> but there are others), you don't need any GUI backend. Independent of >> this issue, it would be great to be able to install python-matplotlib >> in a headless server environment without pulling in all of those GUI >> bits. Looking at the list of the hard dependencies, I don't understand >> why half of them are there. >> >> http://packages.ubuntu.com/natty/python/python-matplotlib > >Would it make sense to split out each interactive backend to its own >Ubuntu package, e.g. python-matplotlib-tk, etc? Each of these would >depend on the relevant toolkit packages, and python-matplotlib would >have a much shorter list of dependencies.
Note that the main/universe distinction happens at the source package level, so we'd have to have separate source packages, ideally with different upstream tarballs. We could finesse that with two different source packages using the same upstream tarball (as suggested in a previous follow up), but I think it would be more difficult to get into Debian, thus precipitating a divergence. Cheers, -Barry
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
