[Dev] Linux package distribution status

[Heikki Toivonen]

Our goal for 0.7 should be that we make it possible for various Linux distributions to take Chandler in the typical (minimal) configuration that most applications are nowadays included in distributions: as packages that depend on other packages. We should also aim to make a Chandler distribution like that (the dependency packages) on at least one Linux platform (since we'll be using Ubuntu it seems the logical choice). So, ideally all of external and possibly some internal libraries will come from system packages instead of us building and distributing everything in a single huge package. Here is where we stand with our libraries so far (non-OSAF): Package OSAF patches required Non-patch reasons why OSAF needs to build and distribute this Notes SOAPpy yes Might not be necessary to have this package dateutil no icu no jabber-py yes Might not be necessary to have this package (not used at all and can be replace with twisted's version -- bear) m2crypto no latest .deb 0.13, Chandler uses 0.15 openssl no Patches are Windows and OSX specific bdb yes libxml2 yes python yes? bzip2 no System python must have been built with bzip2 support zlib no System python must have been built with zlib support readline no setuptools no twisted no Need later version than currently latest release? (need svn version currently -- bear) zope no wx yes These are OSAF packages that seem to be enough standalone that they would merit their own packages: PyICU? PyLucene vobject zanshin The following are Chandler-specific, and should probably be in a single package: chandlerdb chandler If you have any corrections to any of the above, please let us know. We should try to eliminate the need for all of the patches in the third partly libraries. That takes some pushing from us to get those projects to integrate our patches, and release new versions. Failing that, we could try working around some of the issues. If none of that works, we'd need to create OSAF-specific packages for those. The assumption I am making is that all packages that Chandler relies on should be made into .debs whose dependencies (including versions) are already tracked by the Linux tools (Synaptic, apt-get etc.). There is always the possibility that a future version of any library we depend on breaks Chandler, but that is something that all applications on Linux (that rely on the package system) face, so we do not need to try and solve it. Other steps I think we should consider taking is dropping those libraries from our build we don't need. We could also start testing parts of Chandler by relying on as many system libraries as possible - the crucial bit here is Python itself. -- Heikki Toivonen

signature.asc
Description: OpenPGP digital signature

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev