[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