There is a new version of the Horde framework and the other packages that go with it. The new framework is 3.2.x and most of the other <name>-h3-<version> apps also go up a minor number.
The problem with this upgrade is that there is a new database schema and it is a "lots of admin action required" upgrade to a new version. I can't really run the database upgrade SQL script during the upgrade process, so the user is left with a broken system after the upgrade.
With enterprise linux distros, upgrades like this are to be avoided. So the question is ... do we just leave Horde at latest 3.1.x level and use 3.2.X in CentOS-6?
There is the possibility of a horde32 (and all the others apps also as required) and set that to conflict with "horde < 3.2" on C5, BUT that introduces it's own issues.
My feeling is that we stick with the latest horde in the 3.1.x series in CentOS-4 and CentOS-5 (which is 3.1.8) and we wait until CentOS-6 where we will introduce the 3.2.x series (and all the associated apps).
What does everyone else think?
Thanks, Johnny Hughes
Johnny Hughes a écrit :
There is a new version of the Horde framework and the other packages that go with it. The new framework is 3.2.x and most of the other <name>-h3-<version> apps also go up a minor number.
The problem with this upgrade is that there is a new database schema and it is a "lots of admin action required" upgrade to a new version. I can't really run the database upgrade SQL script during the upgrade process, so the user is left with a broken system after the upgrade.
With enterprise linux distros, upgrades like this are to be avoided.
Yes that's really pityfull for end administrators.
So the question is ... do we just leave Horde at latest 3.1.x level and use 3.2.X in CentOS-6?
There is the possibility of a horde32 (and all the others apps also as required) and set that to conflict with "horde < 3.2" on C5, BUT that introduces it's own issues.
My feeling is that we stick with the latest horde in the 3.1.x series in CentOS-4 and CentOS-5 (which is 3.1.8) and we wait until CentOS-6 where we will introduce the 3.2.x series (and all the associated apps).
I you want to follow this way, provide Horde Webmail Groupware Edition 1.1.1, which is one bundle of all associed apps, seems better for me.
What does everyone else think?
Thanks, Johnny Hughes
Jean-Marc LIGER wrote:
Johnny Hughes a écrit :
<snip>
My feeling is that we stick with the latest horde in the 3.1.x series in CentOS-4 and CentOS-5 (which is 3.1.8) and we wait until CentOS-6 where we will introduce the 3.2.x series (and all the associated apps).
I you want to follow this way, provide Horde Webmail Groupware Edition 1.1.1, which is one bundle of all associed apps, seems better for me.
Right, the latest groupware version in CentOS-6 is also an option ... although it is just all the components in one install. It still might be easier to have them broken out. But, the either way, the result is no upgrade that breaks horde now and an upgrade in CentOS-6.
On Tue, Jul 15, 2008 at 6:58 AM, Johnny Hughes johnny@centos.org wrote:
Right, the latest groupware version in CentOS-6 is also an option ... although it is just all the components in one install. It still might be easier to have them broken out. But, the either way, the result is no upgrade that breaks horde now and an upgrade in CentOS-6.
What about an alternate install location, giving users a /horde/ and a /horde32/ location or something similar.
This gives them the option to migrate at their leisure, and lets them do the database operations on their own schedule. We can maintain both in the repository at least temporarily.
Dear Johnny.
The problem with this upgrade is that there is a new database schema and it is a "lots of admin action required" upgrade to a new version. I can't really run the database upgrade SQL script during the upgrade process, so the user is left with a broken system after the upgrade.
Is this a problem with the database sheme or with RPM? Other Distributions like Debian use debconf (which I personally do not really like) to handle post-installation tasks like that.
Also RPM should be able to open a (gtk)dialog based script for configuration. It might also be an option to provide useful upgrade notices and a short link to them after package installation.
Best Regards Marcus Moeller
Marcus Moeller wrote:
Also RPM should be able to open a (gtk)dialog based script for configuration. It might also be an option to provide useful upgrade notices and a short link to them after package installation.
This is totally against (probably any) RPM-packaging guidelines. I expect no CentOS developer would even consider this.
For other distros the solution is fine, as long as they are not RPM-based :)
Regards, Niels
2008/7/16 Niels de Vos niels.devos@wincor-nixdorf.com:
Marcus Moeller wrote:
Also RPM should be able to open a (gtk)dialog based script for configuration. It might also be an option to provide useful upgrade notices and a short link to them after package installation.
This is totally against (probably any) RPM-packaging guidelines. I expect no CentOS developer would even consider this.
For other distros the solution is fine, as long as they are not RPM-based :)
That's what I thought, too. But there is nothing wrong with good upgrade guidelines or different install locations, I guess.
Best Regards Marcus
Marcus Moeller wrote:
2008/7/16 Niels de Vos <niels.devos@wincor-nixdorf.com mailto:niels.devos@wincor-nixdorf.com>:
Marcus Moeller wrote: > Also RPM should be able to open a (gtk)dialog based script for > configuration. It might also be an option to provide useful upgrade > notices and a short link to them after package installation. This is totally against (probably any) RPM-packaging guidelines. I expect no CentOS developer would even consider this. For other distros the solution is fine, as long as they are not RPM-based :)That's what I thought, too. But there is nothing wrong with good upgrade guidelines or different install locations, I guess.
No, thats what I think too. Repackaging into hord32-RPMs is probably most sane to do. Those who want to use the newer version will just need to install hord32-... instead of hord-... This way even configuration files and databases could be kept separately. For upgraders (manually?) http://www.horde.org/horde/docs/?f=UPGRADING.html might be a good reading.
Thats just my €0,02. Niels
-
Jean-Marc LIGER -
Jim Perrin -
Johnny Hughes -
Marcus Moeller -
Niels de Vos