[sword-devel] Debian and Ubuntu packages
jmarsden at fastmail.fm
Fri Jan 23 09:55:41 MST 2009
Peter von Kaehne wrote:
> 1) Diatheke - we should rebadge the CGI scripts as "examples" or remove
> them due to the security issues associated with them.
This is pretty simple to do, either at package build time or (of course)
it can be done in the original upstream code if Crosswire as a whole
agrees with the idea.
> 2) libsword - one Ubuntu MOTU complained that we do not publish a
> detailed list of API changes (vs general bug fixes) from version to
> version. At least he could not find it. I guess this is a fair point.
To clarify, this is so that it is clear exactly when to "bump" (increase
by one) the SONAME of the library. Library packaging in Debian/Ubuntu
is regarded as harder than "normal" application packaging, and this
issue of potentially needed multiple versions of a library around to
handle different apps that may each require a specific version of the
library, because of API changes over time, is a major part of that.
It seems your source code handles this by using the 1.5.11 style version
as the SONAME, so changing library version with every release; that is
not likely to be acceptable in Debian or Ubuntu so we need to patch this
during packaging; existing Debian/Ubuntu packages currently use 6 as
the library version, it seems.
Without knowing whether all apps that link against (say 1.5.9 can in
fact run against 1.5.11, and vice versa, theer is no way for a packager
to decide when a "SONAME bump" is needed for a given new release.
> 3) dependencies - I think we need to do some work on convincing them
> that our modules should be classified as e-books (and subsequently not
> packaged) rather than as "updates" or "plugins" and hence packaged.
> Otherwise they will continue to package bibles etc.
Definitely -- and that will be hard work; note that many games with
large datasets package that data as packages, for example; your approach
is far away from Debian and Ubuntu norms in this area. If the modules
chaneg so fast that very frequent updates are needed for them, you might
consider a dual strategy -- package a core subset of them for shared
packaged installation and leave the rest for per-user "dynamic" download
by users? This area is going to need some work and some give and take.
> I have bcc'ed my correspondents + volunteer aspirants among the Ubuntu
> lot and hope that some will join this thread on the mailing list + we
> can get the ball rolling again.
I'm here, or I hope I am... my subscription to the list seems to have
been held pending moderator approval??
More information about the sword-devel