Split Plash into multiple source packages
Status: in progress
Split the Plash source package into multiple source packages, buildable by JHBuild.
The source packages would be:
- Plash C library, to be installed as libplash, with header files provided by a -dev package
- C versions of pola-run and pola-shell (though there are obsolete)
PlashGlibc, providing /usr/lib/plash/lib. Another version of this would be built to provide files under /lib.
- Python libraries and scripts, including pola-run.
- Maybe plash_pkg should be separate.
Test cases for PlashGlibc
ChrootSetuidJail, providing /var/lib/plash-chroot-jail. This is the only part that requires root access to install.
This depends on Story16 (don't require ld-linux.so.2 to be inside ChrootSetuidJail).
Gtk preload hack (GtkFilePowerboxHook), although this will eventually be superseded (see Story20). Include test cases.
In the future, there will also be:
- a branch for patches to Gtk
Might consider redoing the build processes for these modules to use GNU autotools. For example, libplash can use libtool.
We should need only minimal Debian packaging for each module. Ideally the Debian scripts should be automatically generatable. Reducing the amount of Debian packaging could make it easier to build RPMs.
This split should make it easier to work on subsets of components. People more comfortable with Python would not have to rebuild PlashGlibc, which takes a relatively long time. The components could be installed to a prefix (with ./configure --prefix=...) or built as .debs.
For comparison, GNOME, Xorg and OLPC Sugar can be built with JHBuild, which is primarily a development tool which sets up working copies. Xorg went through a similar transition from a monolithic package to multiple packages. Zero-Install is also made up of multiple components, which happen to be versioned separately.
Directory organisation in SVN
One approach is to continue having a single set of "trunk", "branches" and "tags" directories (the "unified trunk" approach). The trunk directory would be broken down into:
- trunk/libplash
- trunk/python-plash
- etc.
The alternative is for each module to have its own "trunk", "branches" and "tags" directories.
The unified trunk approach is slightly unconventional. However, it makes it easier to check out all the modules in one go. It makes tagging easier, because tagging can be done in one operation. It makes it easier to commit across multiple modules. JHBuild would need changing to support this arrangement.
Note that not all modules will be in SVN. PlashGlibc is kept in Git.
Tasks
Move everything in "trunk" down a level, to "trunk/plash".
Change BuildTools to handle this.
- Fix all the SVN links on the wiki
Split out plash-chroot-jail.
Change BuildTools to handle multiple Debian packages.
Add a plash-dev package containing header files, so that GtkFilePowerboxHook can be split into a separate package (also necessary for Story20)
Added a plash-dev package containing a static library (libplash.a)
- Switch to providing a dynamically-linked library (libplash.so)
- Should it be called libplash-dev?
- Remove header files from /usr/include/plash that should not be exported
Make sure that all C definitions are namespace-clean, i.e. start with a pl_ prefix. This is quite a big task so it will probably not get done for a while and it should be tracked on a separate story page.
Split GtkFilePowerboxHook into a separate package
Add it to BuildTools' list
- Move vtable definitions for gtk-powerbox.c out of plash/src/make-vtables.pl
Move BuildTools out of "scratch" and into "trunk"
- Make sure that all Debian packages have useful long descriptions
- Make sure that copyright messages in source files and in /usr/share/doc/*/copyright are up-to-date