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

[Robin Sheat]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20140610/2d6dd699/attachment.pgp>