[postgis-devel] PSC Vote: Get rid of upgrade paths from 2.0 - 2.3 for PostGIS 3.5+

Greg Troxel gdt at lexort.com
Tue Aug 22 11:54:09 PDT 2023


Sandro Santilli <strk at kbt.io> writes:

> On Sun, Aug 13, 2023 at 05:59:35PM -0400, Regina Obe wrote:
>> > On Sat, Aug 12, 2023 at 12:23:02AM -0400, Regina Obe wrote:
>> > > Anyone who has an opinion on this matter, feel free to chime in.
>> > > Every time I package it annoys me I have to ship 100s of useless files.
>> > 
>> > Here's my solution:
>> > https://trac.osgeo.org/postgis/ticket/5092#comment:6
>> > 
>> > That solution will drop the file count to 1 * (number of extensions)
>> 
>> But that's only going to work for PG17+ assuming we can convince Tom it's an
>> okay idea.
>
> What I meant was for --without-upgrade-scripts install to become the
> default.
>
>> I want the old files (2.1-2.3 gone) even for PostgreSQL < 17. I doubt anyone
>> needs them and if they do
>> Then they can use the new postgis install-extension-upgrades command.
>
> Fine by me to trim that list down, but note the presence of those
> scripts is what determines which upgrades are tested by ci, via
> utils/check_all_upgrades.sh

No they can't use that command, because when they install a binary
package the source is not present.


My view is that almost all uses of successful software are via a
packaging system.  Of course developers of each piece  almost never use
that software via packaging.   So we really need to try hard to think of
the flow from

  source control
  release tarballs
  binary packages from packaging systems
  users with the pacakge installed and no source code

when considering how things work.


More information about the postgis-devel mailing list