GNOME Bugzilla – Bug 633592
Decrease Banshee's install footprint
Last modified: 2010-11-15 17:44:57 UTC
There are various issues adversely affecting Banshee's install footprint: 1) gdata-sharp relies on System.Web which pulls in WCF. I submitted a patch removing that dep at https://code.google.com/p/google-gdata/issues/detail?id=429 2) System.Data.dll (which our sqlite layer relies on) is packaged with System.Data.Linq which uses System.Runtime.Serialization which is in WCF. Options include splitting S.D.L out into its own package that deps on WCF, or changing Banshee to not use System.Data at all (but a simpler direct binding of sqlite). 3) In Ubuntu at least, translations are currently bundled into the banshee.deb, roughly doubling its size. Hyperair tells me they will be split out when banshee enters 'main'. Please add concrete information about any others you know about. This bug will serve as a tracking bug for these disparate issues.
A nice graph of the dependencies of Banshee on Debian/Ubuntu : http://people.ubuntu.com/~hyperair/banshee-dep.png Items in red are the ones that can be removed by 1) and 2)
The WCF part of 2) isn't Banshee's problem, it's a Mono packaging issue in Debian/Ubuntu. However, switching to a different database library would lead to some significant gains as per Hyperair's graph. Alternatively, a good start would be to find a way to drop SQLite2 support entirely from Mono.Data.Sqlite, since it pulls in SQLite 2.x as well as 3.x - I don't think we care much as a distro about SQLite 2 support in the library, so if we can patch it out of Mono.Data.Sqlite without breaking existing 3-using apps, that'd be great.
(2) is now taken care of -- I replaced Banshee's usage of Mono.Data.Sqlite with a custom binding with no additional deps.
I'm going to close this bug, I think we're in a pretty good place now size-wise.