A note about the squeeze-dev repo
I've just updated the koha in squeeze-dev to the latest master. However this won't update automatically, as 3.15.1 was in there previously (to force an update for the security update a few months back), and now the version is back to 3.15~git... Prior to the security update, the version was 3.15-1, but due to a more strict enforcement of the debian policy in recent versions, we have to drop the -1 part. So, if you are using packages from master (for testing purposes only, of course :), you'll want to do: sudo apt-get install koha-common=3.15~* to force the "downgrade" to the current version. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Hi, On Mon, Apr 14, 2014 at 11:45 PM, Robin Sheat <robin@catalyst.net.nz> wrote:
I've just updated the koha in squeeze-dev to the latest master. However this won't update automatically, as 3.15.1 was in there previously (to force an update for the security update a few months back), and now the version is back to 3.15~git...
Prior to the security update, the version was 3.15-1, but due to a more strict enforcement of the debian policy in recent versions, we have to drop the -1 part.
So, if you are using packages from master (for testing purposes only, of course :), you'll want to do:
sudo apt-get install koha-common=3.15~*
to force the "downgrade" to the current version.
Thanks! I'd like to tack on a semi-related (or possibly not at all related) question. Should we consider adopting a different set of code names/suites for our APT repository? For example: testing stable oldstable (maybe) reallyoldstable or perhaps go by version number (modified as needed to confirm with any toolchain expectations about the format of the suite name)? 3.16.x 3.14.x etc. Doing this would avoid any implications about which particular OS releases a given package can work with. Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Greetings, Galen wrote:
Should we consider adopting a different set of code names/suites for our APT repository? For example:
testing stable oldstable (maybe) reallyoldstable
Yes, I think we should rename them. Renaming repositories in general as needed: +1 Rename squeeze to stable: +1 Rename squeeze-dev: +1 -- You'll note that I'm not sure whether it should be 'testing' or 'development'. Keeping reallyoldstable: -0 -- I'm kind of on the fence. It would be great to install an older stable version, but what is the point of hosting it, when someone could follow the instructions on the wiki (http://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way, for example) and roll their own earlier distribution from a git installation.
or perhaps go by version number (modified as needed to confirm with any toolchain expectations about the format of the suite name)?
Renaming by version number: -1 -- I don't think having to do the modifications gives us added benefits, does it?
Doing this would avoid any implications about which particular OS releases a given package can work with.
Which is a good thing! GPML, Mark Tompsett
Hi, On Tue, Apr 15, 2014 at 10:28 AM, Mark Tompsett <mtompset@hotmail.com> wrote:
Keeping reallyoldstable: -0 -- I'm kind of on the fence. It would be great to install an older stable version, but what is the point of hosting it, when someone could follow the instructions on the wiki (http://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way, for example) and roll their own earlier distribution from a git installation.
By that logic, why should we host an APT repository at all? The answer, of course, is to make supported versions of Koha easy to install. I think we should be leery of directing folks at instructions on how to roll their own packages unless they are doing development for Koha or are an entity that is providing their own support for an officially unsupported version of Koha. This ties into a broader question of how many versions we want to support. My view is that we "officially" support a version, we should provide packages for it (depending of course, on the availability of people and tools to build them).
Renaming by version number: -1 -- I don't think having to do the modifications gives us added benefits, does it?
Well, there's a potentially a rather big benefit: not surprising somebody who is tracking stable with a major version upgrade, particularly since Koha falls in the category of usually being the primary reason why a given server/VM exists Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org
Galen Charlton schreef op di 15-04-2014 om 10:15 [-0700]:
I'd like to tack on a semi-related (or possibly not at all related) question. Should we consider adopting a different set of code names/suites for our APT repository? For example:
My answer here is "yes, but..."
testing stable oldstable (maybe) reallyoldstable
We probably need to deprecate the squeeze* names, however they do serve a potential purpose. That is, if we need to build a different version for different OSes, then we can. However, I don't think this is likely, and we'd be better off actively avoiding that being a thing we need to do. Given this, I'd lean towards the names you list above. I think I can actually make this happen just by setting up some symlinks in the repo.
or perhaps go by version number (modified as needed to confirm with any toolchain expectations about the format of the suite name)?
3.16.x 3.14.x etc.
I've thought about this, and I don't like it. The main reason is that if people just want to regularly update to be either more bleeding edge or a bit more conservative, they can track squeeze or oldstable respectively. If the distribution names are version numbers, then there's no seamless upgrade path when a version is retired. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
Agree wholeheartedly with the above, it would be nice to have testing,stable,oldstable repos instead of OS specific. (we've been using the 'squeeze' repo on our wheezy machines for ages now). Also agree with Robin, that I don't like version number specific repos, for the same reasons. A clear upgrade path. Martin Renvoize Software Engineer, PTFS Europe Ltd Content Management and Library Solutions Skype: Landline: 0203 286 8685 Mobile: 07725985636 http://www.ptfs-europe.com On 15 April 2014 23:59, Robin Sheat <robin@catalyst.net.nz> wrote:
Galen Charlton schreef op di 15-04-2014 om 10:15 [-0700]:
I'd like to tack on a semi-related (or possibly not at all related) question. Should we consider adopting a different set of code names/suites for our APT repository? For example:
My answer here is "yes, but..."
testing stable oldstable (maybe) reallyoldstable
We probably need to deprecate the squeeze* names, however they do serve a potential purpose. That is, if we need to build a different version for different OSes, then we can. However, I don't think this is likely, and we'd be better off actively avoiding that being a thing we need to do. Given this, I'd lean towards the names you list above.
I think I can actually make this happen just by setting up some symlinks in the repo.
or perhaps go by version number (modified as needed to confirm with any toolchain expectations about the format of the suite name)?
3.16.x 3.14.x etc.
I've thought about this, and I don't like it. The main reason is that if people just want to regularly update to be either more bleeding edge or a bit more conservative, they can track squeeze or oldstable respectively. If the distribution names are version numbers, then there's no seamless upgrade path when a version is retired.
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5FA7 4B49 1E4D CAA4 4C38 8505 77F5 B724 F871 3BDF
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (4)
-
Galen Charlton -
Mark Tompsett -
Renvoize, Martin -
Robin Sheat