M. Edward (Ed) Borasky wrote:
> PostgreSQL is a good example - 9.4 is in the release candidate stage
> right now and will probably be declared stable within a month. If it
> doesn't at least make it into updates-testing before F22, I'll be
> adding 9.4 from the PostgreSQL project's RPM repos or building it from
> source. I need a major new feature - Binary indexable JSON storage.
> GDAL and QGIS are other examples; I ran for a couple of months
> building gdal 1.11.0 from source and installing QGIS from non-Fedora
> repos because I needed those features and they weren't in
> updates-testing.
The updates-testing repository is only supposed to be used for packages that
will eventually hit the regular updates repository. It is NOT a dumping
ground for incompatible upgrades.
And unfortunately, a new PostgreSQL IS incompatible, because if you just run
"yum update", your databases will cease to work. You have to actually dump
them BEFORE doing the upgrade (or downgrade PostgreSQL for the dump, or
install the old version in parallel, which is not supported by the RPMs),
then do the upgrade, and then import the dump. As long as upstream does not
change this migration policy, it will NEVER be possible to provide newer
PostgreSQL release series un updates.
I am generally in favor of doing version upgrades in updates, but when they
are disruptive, as in PostgreSQL's case, it's just not possible. Cases where
an upgrade does not make sense in updates include, but are not limited to:
* not being able to load user data (which includes databases and documents,
but also configuration files, game savestates, etc.) from the previous
version, or requiring manual migration for it (see PostgreSQL),
* removed features,
* major UI changes,
* soname bumps in libraries used by too many packages for a grouped update,
etc.
For QGIS, I don't know whether a version upgrade is possible in a stable
release (see above), but I can check with the maintainer (Volker Fröhlich),
or you can ask him directly.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
