[Koha-devel] On Koha Debian apt repository layout and package versions

Tomas Cohen Arazi tomascohen at gmail.com
Wed Apr 30 17:24:09 CEST 2014


---------- Forwarded message ----------
From: Lars Wirzenius <liw at liw.fi>
Date: Wed, Apr 30, 2014 at 12:21 PM
Subject: On Koha Debian apt repository layout and package versions
To: tomascohen at gmail.com


Hi,

I made some Debian packages for Koha in 2010, on contract to Catalyst,
Ltd, and then left the Koha community. The packages are now maintained
by Robin and others. I still lurk on the IRC channel, but I don't
follow the mailing lists. I happened to notice recently that there was
some discussion on maybe renaming the apt package repositories. I
spoke up, and was directed to the mailing list thread starting at [0].
It's a short thread. I offer the following thoughts on the topic, in
the hope they're useful.

[0]
http://lists.koha-community.org/pipermail/koha-devel/2014-April/040428.html

First, a little background. Debian apt package repositories may
contain many versions of a package, by grouping things into "pockets".
The concept has various names in various corners within Debian, and
the greater Debian derivatives community, but I'll use this name for
simplicity. Each pocket has a name, which is a subdirectory under the
"dists" directory in the apt repository. This provides a single
dimension for supporting multiple versions, and is used for different
Debian releases. Debian has the pockets "stable", "testing",
"unstable", and "experimental", where "stable" is the release users
are expected to use, unless they're interested in participating in
Debian development.

Those pockets are actually aliases (via symbolic links) for code names
for Debian releases: "squeeze", "wheezy", and "jessie" are names of
three Debian releases. The releases also have version numbers, but
this is not evident in the apt repository.

In addition to the major pockets (one per release), there are some
additional ones, such as one for "backports" (e.g.,
"wheezy-backports"). This allows the apt repository to allow more
versions of a package, for different users. For example, the
"wheezy" pocket might have version 1.1 of some application, and
"wheezy-backports" might have version 2.0, but built for the "wheezy"
release. This is different from having 2.0 in the "jessie" pocket,
since the binary package is different depending on where it is built.
For example, the build for "wheezy-backports" might depend on
different versions of, say, some Perl modules, than the one in the
"jessie" pocket.

This structure works reasonably well for Debian.

For Koha, I suggest that the following questions should be answered
before changes are made to the repository structure.

* Which versions of Koha does the community want to support? Do you
  have stable versus alpha versus beta versus some other branches? Do
  you have "long-term support" releases?

* When do you want sysadmins to upgrade their Koha packages? Do you
  want to give them maximum flexibility on this, or do you want to
  force upgrades when you make a Koha release?

* Do you care about producing builds for a variety of releases of
  Debian or Debian derivatives? Do you care about building for more
  than the current Debian stable release? Maybe the current stable,
  and the previous stable release?

My knowledge of Koha is years out of date, but from what I remember
and from what I understand from lurking, here are my thoughts (and
please excuse me if you know all of this already, and already do all
of it):

* I think it makes sense, if you can automate it, to build for the
  current Debian release ("stable"), and the previous Debian release
  ("oldstable"), and also the current Debian development version
  ("unstable").

  Building for the two releases means that those who install the
  packages get to choose when they upgrade their operating system,
  without Koha forcing an upgrade. If you only build for the current
  Debian stable, you force Koha sysadmins to upgrade when Debian makes
  a release.

  Building for Debian unstable (or possibly testing) means that you
  catch incoming changes in Debian sooner rather than later. For
  example, when Debian upgrades their Perl, you'll learn soon if it
  affects Koha.

  These pockets should probably be named after the Debian releases.
  Currently that would mean pockets named "squeeze", "wheezy", and
  "unstable". That is, the pocket should be named according what the
  user is running, not what version of Koha it contains. This keeps
  things simple for the user, and keeps the number of pockets
  manageable.

* I think it makes sense to build at least two versions of Koha: the
  current Koha release, and the current tip of the master branch.
  These packages should have different names, so they do not conflict
  in the apt repository. The apt repository keeps all package files in
  "the pool", whereas the "dists" directory only contains lists of
  packages and versions.

  The stable Koha release should probably be called "koha". The
  tip-of-master should be called something else, perhaps
  "koha-dangerous" to scare people away from installing it without
  knowing what they do. The two packages could be co-installable, if
  that make sense for Koha.

  The dangerous package would allow anyone to easily try out the
  latest Koha, and if the package is built any time master changes,
  it'll be easy to keep up to date. This may be easier than running
  Koha directly from git.

* If you think it is worth it, it may be worthwhile to have more than
  one Koha release in each pocket. It might be to support the latest
  release plus an LTS release, or to have several stable releases, for
  example to release bug fixes to older releases as well.

  If you decide to do this, the cleanest way, in my opinion, is to
  have packages for each supported release or branch: "koha-3.10",
  "koha-3.12", and "koha-3.14". These packages would have the latest
  version of that branch. For example, there might be version 3.10.07
  of the koha-3.10 package. This way, someone who wants to stay with
  Koha 3.10, will install the koha-3.10 package. If there's a new bug
  fix release of 3.10, the package is updated, and they upgrade to the
  new package version in the usual way ("apt-get upgrade"). However,
  they're not forced to upgrade to a newer version of Koha and can do
  so when they're ready.

  In addition, there would be an empty package "koha", which would
  depend on the latest Koha release, for those who do want to have
  that, with a minimum of fuss. This would allow one to install the
  package koha, and then get the latest version, even when latest
  version changes from 3.14 to 3.16.

So, in summary, I recommend:

* Have pockets "squeeze", "wheezy", and "unstable".
* Have packages "koha", "koha-x.y" (for a set of versions you want to
  provide), and "koha-dangerous" (for latest git commit).

I hope this helps, and I apologise for the verbosity of this. I had
some time while waiting for a train, but the train came before I had
time to squeeze out the fluff from this.

(Please Cc me on any replies you wish me to see, as I unfortunately do
not have the cerebral cycles to follow the Koha mailing list at this
time.)

PS. Despite only participating in the community for three months, I
remember it very fondly. You do good work, and you make the world a
better place. And you're nice and polite while doing it.
Inconceivable!

--
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140430/2c6657ba/attachment.html>


More information about the Koha-devel mailing list