[postgis-devel] PSC Vote: Get rid of micro in PostGIS Extension scripts (and comments from others)

[Regina Obe]

> > Given the above I don't see a way to reduce pollution other than
> > avoiding the OLD.SPECIFIC.THING--CURRENT.INSTALL.VERSION but rather
> > alwyas override the same OLD.SPECIFIC.THING--ANY path, which you
> > mentioned, Regina, as being something that packagers don't like.
> > Do you confirm, Greg, that you don't want a file like:
> >
> >   postgis--2.0.0--ANY.sql
> >
> > Installed by multiple contending versions of PostGIS ?
> > The idea is that file would mostly always have the same content (no
> > content at all).
> 
> I don't follow why you would think I'd object.  I guess the core question
is
> whether it is reasonable to install two versions of postgis at once.  If
that's
> going to work then everything has to be versioned.
> Right now shp2pgsql for instance, is not, and that's good because users
> expect postgis to provide that command.

That was because I said packagers may object.
But we have the same issue with the postgis.control file, so perhaps not a
huge issue.

It doesn't solve the problem though that we still have to have a path to ANY
for every micro version.

> I am not that happy about every time I update the package there are a
whole
> bunch of new files -- especially for beta versions -- that I have to add
into
> PLIST.  But it seems necessary (except for beta/rc stuff, which I think
are best
> left to people that use those to cope with) so I
> don't complain.
> 
> 
> In pkgsrc we do have multiple  versions of pgsql but I don't think we
> allow multiple versions to be installed; it's a choice.   postgis can be
> built against the installed pgsql version, and there is only one version
of
> postgis.
> 
> Note that while I just described pkgsrc the way packaging systems deal
with
> this issue is quite variable.

That was the point of getting rid of the MICRO which pramsey had suggested,
but no one liked that idea except for me and pramsey.
My argument is few sql scripts change in micros, and when they do, we can
have a round-robin loop so that a user can always be upgraded using

SELECT postgis_extensions_upgrade();

So we don't loose much except those damn extra files.

On windows people are allowed to have multiple different major installed
versions of PostGIS in the same cluster.
e.g. you can have 2.5, 3.2

But for the production install you can't have 3.1 and 3.2. But if we get to
a 4.0, then you can have 2.5, 3.2, and 4.0

But windows is an  odd-ball in this case and also given we got rid of the
micro already on the LIB file, it really isn't realistic for production
users to be having multiple minor versions of PostGIS.  So perhaps that
makes the overwriting minor files less of a concern.

-- Regina Obe