[Slackbuilds-users] PostgreSQL - multiple installed versions

JK Wood joshuakwood at gmail.com
Wed Sep 4 03:12:39 UTC 2013

On Sep 3, 2013 10:03 PM, "Benjamin Trigona-Harany" <bosth at alumni.sfu.ca>
> On September 3, 2013 17:04:15 Adis Nezirovic wrote:
> > Guys, I have a question for all PostgreSQL users and SBo admins.
> >
> > Would it be OK for the next PostgreSQL package (upcoming 9.3) to be
> > specific and parallel-installable with  old PostgreSQL versions.
> > (of course, we would continue that practice in the future).
> >
> > Since PostgreSQL installations are not upgradeable in place, one needs
> > do export/import data cycle or use pg_upgrade utility, and having old
> > new database instance would be very handy for that.
> >
> > The packages would be named postgresql93 (v9.3.x), postgresql94 (v9.4.x)
> > (the current postgresql can be treated as postgresql92), and would use
> > version specific data directories.
> This is timely because a similar issue just came up with the 2.2 release
> PostGIS, which also expects both the current 2.2 and the previous 2.1
> installed to do an in-place upgrade of existing databases.
> However, providing both postgis21 and postgis22 SlackBuilds would mean
> headaches for packages depending on PostGIS since it wouldn't be evident
> version of PostGIS it was built against without also versioning that build
> script.
> Likewise, splitting PostgreSQL into version-dependent scripts is going to
> affect dependencies. Other distros have ended up with packages such as
> postgres91-postgis21-2.1.0, but I don't see that being maintainable,
> especially when we consider the further SlackBuilds that will depend on
> package.
> Ben
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/

Speaking as someone who works with databases professionally, if you don't
have a way of maintaining an upgrade path you have bigger problems.

Speaking as someone who maintains a few packages, having two differing
packages won't solve the problem, which is overwriting the tools when you
install the new package.

It really sounds to me like an upgrade script which takes care of the
necessary steps for an upgrade would be infinitely preferable, and should
be done in addition to the current SlackBuild.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20130903/ba05ab33/attachment-0001.html>

More information about the SlackBuilds-users mailing list