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