On Koha Debian apt repository layout and package versions
---------- Forwarded message ---------- From: Lars Wirzenius <liw@liw.fi> Date: Wed, Apr 30, 2014 at 12:21 PM Subject: On Koha Debian apt repository layout and package versions To: tomascohen@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
I think there's allot of merit to Lars's suggestions and personally think the final approach to be the most sensible, allowing users to stick to a stable supported version without being forced to upgrade every 6 months in our case, to a .0 release. I do have a couple of questions however, and these are the reasons I believe the original bug requesting such a change was changed to 'RESOLVED - WONTFIX'. Lars, could you comment on upgrade paths between versions if we moved to having koha, koha-3.12 and koha-3.14 versions per pocket? (i.e., how does one seamlessly switch from koha-3.12 to koha3.14 when they chose to do so.. I'm sure this has all been solved before, but I'm unaware how), and importantly how to you 'end of life' a version once say koha-3.10 is unsupported, is there a method to notify a user to switch? Your input on those tow points would be most appreciated. Martin Renvoize (Ashimema on IRC) Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com
Renvoize, Martin schreef op do 05-06-2014 om 20:19 [+0100]:
I think there's allot of merit to Lars's suggestions and personally think the final approach to be the most sensible, allowing users to stick to a stable supported version without being forced to upgrade every 6 months in our case, to a .0 release.
I'm not opposed to the idea in general. There are just a couple of issues with it that would need to be resolved. So, for context, the current method is that there are three pockets: * squeeze-dev * squeeze * oldstable The 'squeeze' part is inaccurately named now. At some stage I plan to move it do something like koha-devel (though I like koha-dangerous), stable, and keep oldstable. We don't yet distinguish OS releases, and it's something I'd /really/ like to avoid. At this stage I do the build on a Squeeze chroot, and will do that until we either a) decide we aren't supporting squeeze any more, or b) it simply becomes too much hassle to do so for some reason, probably something to do with new dependency requirements that can't be built there. Squeeze-dev contains master, and is updated periodically. Squeeze tracks the current stable release and will get the .00 releases. It'll also go from, e.g., 3.14.xx to 3.16.00. Oldstable tracks the stable release series prior to the current one, so it usually starts with .06 or .07 releases, and never sees a .00 release. Essentially, the current practice means that you can err on the side of bleeding-edge, or you can be more conservative, but you're always supported. Now, the other approach is that we have koha-3.14, koha-3.12, etc. that depends on the current release of that series. We could also have a koha-stable, koha-oldstable for people who want to track things like the current way. However, the problems with this are: * We'll be building more packages, which is currently a fairly manual process (though I'm working on solving that, slowly.) * Keeping people current is harder. * What do we do with the koha package as it stands. I'll ignore the package building thing, it just needs me to sit down for a day or so and finish the script I'm working on to magically do everything and not make mistakes. However, having a collection of tracking packages would necessarily cause more overhead. But the keeping people current thing is more of an issue. If someone installed koha-3.10, they'd still be on 3.10, and it's not really supported. We have no way of prodding them to move to 3.16 or whatever when it's no longer receiving fixes for things, especially security thing. Now, they can have koha-common 3.10.02 installed if they want, and not upgrade it. There's nothing that /forces/ them to do that. But they are at least encouraged to. Essentially, the way I see the current system is that you have a couple of ways of ensuring you're up to date: be quite current, or be more conservative. We don't have to be everything to everyone, we can just do what is best for most of the people. Anyone who wants something different can always build their own packages, which isn't terribly difficult if you know much about Debian. We'd also have to figure out what to do with the existing Koha package. It's always been my plan that installing that would give you a preconfigured system, but a) I don't think I'll ever get around to doing that, b) it's harder than it seems, and c) no one else seems to want/need/care about that either. So stripping it out and replacing it isn't a big deal Now, I'm not writing off the more fine-grained method. It would solve a couple of problems, for example we wouldn't need to have pockets in the repo for the different versions, so that complexity is lower, even if overall it'd be higher. But I think we do need to carefully consider what problems we're trying to solve, are they really problems, and will this solve them without introducing more? -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
participants (3)
-
Renvoize, Martin -
Robin Sheat -
Tomas Cohen Arazi