Re: [pgsql-pkg-debian] amcheck packages

Re: Peter Geoghegan 2017-10-02 <CAH2-Wz=2K6_bUJcYjFCKqQEmDsCZFQrY1Dcvx5Szj7pwYDi6oQ@mail.gmail.com>
> I pushed a version that makes those changes. Please let me know what
> you think, particularly about the versioning style (package version
> vs. extension version).

Looks good.

Re the versioning, I think package and extension versions should be
independent, so that releasing new versions that don't affect the SQL
part don't need to bump the extension version number. What I've been
doing for my extensions (e.g. unit) is to use a single integer as
extension version (currently 4), and release 4.0 from that. The
"SONAME" approach would be to use completely different version
numbers, e.g. SQL version 1, and release 0.3.

Mixing 0.3 and 0.4 otoh sounds rather confusing.


Re: Peter Geoghegan 2017-10-02 <CAH2-WzmO++VVtDrY1FTiSy2cNdJdMvi2OjkR5eMgZU7h2O_1kg@mail.gmail.com>
> > If it's really the same extension, just a newer codebase, why not have
> > 1.0 in PG10, and use 1.1 here. Renaming the extension somewhat implies
> > it would be co-installable with the original.
> 
> They could be co-installable, by changing symbol names. There is going
> to be a contrib amcheck 1.1 before too long, so if I'm not going to
> change the name of the extension, I should at least make sure that the
> version numbers stay in a non-overlapping range, to make sure that
> there is never confusion during upgrade.

Does it make sense to have both variants installed, is it safe to use
both that the same time? If the SQL names conflict, that would
(nicely?) prevent co-installation on the SQL side.

> I am tempted to increment versions ahead of extension version, for
> C-only changes. That would allow me to create a 0.4-1 without changing
> or adding any SQL files. What do you think of that idea? Any
> particular reason why I should favor extension/package version 1.0,
> that I might have missed?

1.0 isn't special, maybe except for general style in contrib
extensions... no idea.

> I don't believe that that's critical, since we default to unsafe. The
> Postgres contrib version is PARALLEL RESTRICTED on general principle,
> not because it matters. Leaving this out means I don't have to deal
> with special cases on Postgres versions that don't know about
> parallelism.

Oh, ok. (I have yet to read up on the whole parallel stuff...)


Re: Peter Geoghegan 2017-10-03 <CAH2-Wzn7m4CO04rbYky3GJC1ACN42cqXqsNvmt82nS=ZF-m-BQ@mail.gmail.com>
> Without this, the control file of the external version simply
> overwrites the contrib version as part of "make install". That's
> clearly not okay.

On the dpkg side, the package would be uninstallable because the file
lists conflict.

The .so file would also need renaming, btw...

Christoph


-- 
Sent via pgsql-pkg-debian mailing list (pgsql-pkg-debian@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-pkg-debian