[postgis-devel] Upgrade paths (again)

[Greg Troxel]

Sandro Santilli <strk at kbt.io> writes:

> On Wed, Sep 14, 2022 at 08:31:11AM -0400, Greg Troxel wrote:
>> Sandro Santilli <strk at kbt.io> writes:
>> > On Sun, Aug 14, 2022 at 06:50:13AM -0400, Greg Troxel wrote:
>> >> Sandro Santilli <strk at kbt.io> writes:
>> >
>> > There is no "right bits" as those depend on the status of the machine.
>> > What's "right" depends on what versions users need to upgrade from,
>> > thus the script (which can only partially determine that, in its
>> > current state).
>> 
>> I see.  Well, my view is that in packaging we try to push as many things
>> into "build", and do as little as possible/reasonable at install time.
>> 
>> And, at package installation time, it is quite possible that pgsql is
>> not running, and the package manager probably doesn't have database
>> privs.
>
> I've changed the 'upgrade-paths' code so to not require PostgreSQL at
> all but keep the current model of installing explictly stated upgrade
> paths from old supported versions. The new aim is simply avoiding the
> need to run updates on system catalogs.

Who is explicitly stating this and when?

Building a binary package has to have the same outcome whether or not
postgis has ever been set up or in varying versions on the build
machine.

Anything that isn't in the binary package isn't available to the user.

Are you saying you want to pivot from:

  have the build/install process (and thus what is packaged) install
  upgrade scripts from N old versions to the current version

to

  have the build/install process install some proto-upgrade-scripts and
  also some program (perhaps a shell script) that, can be run something
  like

    postgis-generate-upgrade-from 2.5.1

  and will output the upgrade script?  Or also run it?   Or maybe just
  query all the databases and do it, but it has to be a pgsql superuser,
  or only upgrade databases it has privs on?


From the packaging point of view, if you want to change the upgrade
process it doesn't bother me.  But the "make && make install" cannot
look into anything about the current system.  That breaks reproducible
builds (not claiming we are fully there but a change in the set of
installed files based on the current state is a bug) and will make the
resulting package non-portable.

> The new packaging problem with this model is that the SAME file would
> be included in multiple packaged postgis versions, namely upgrade
> paths in the form:
>
>     postgis--3.0.0--ANY.sql

I don't understand why that's a problem.  That file, for packaged
version N, is how to upgrade from 3.0.0 to N.  It has the same name, and
different contents, for every value of N.  That's true of most files in
a package and it isn't a problem.

A key point where we may be talking past each other is that when you
upgrade a package, then every file that was previously installed --
expect for special treatment of user-generated config files like
/usr/pkg/etc/foo.conf -- are removed.  These upgrade scripts are
definitely not user-generated config files; they are programs.  So it's
fine to have a different script in postgis-N and postgis-M with the same
name.  Not only fine, but it seems normal and straightforward to me.

> The above file would be installed by all future postgis versions.
>
> This is the reason why I'm thinking we should not install them
> (nor include in the binary packages) at all but delegating that
> operation to the system administrator. But I agree it would not
> be easy for the system aministrator  (or DBA?) to tell what
> version of postgis the available databases might be using, which
> basically means iterating over all databases and gathering this
> info:
>
>     select extversion from pg_extension where extname = 'postgis';

I don't understand why you don't want to install them, other than that
there are many of them.

If you don't, then what is a DBA supposed to do?  Where are they going
to get the upgrade scripts from?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20220914/13d025be/attachment.sig>