[Pkg-postgresql-public] plv8 is marked for autoremoval from testing

[Debian testing autoremoval watch]

plv8 1:1.4.10.ds-1 is marked for autoremoval from testing on 2017-09-30

It (build-)depends on packages with these RC bugs:
760385: libv8-3.14: nodejs: CVE-2014-5256
773623: libv8-3.14: nodejs: CVE-2014-7192
773671: libv8-3.14: multiple security issues
853512: libv8-3.14: ftbfs with GCC-7


___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Ole Streicher]

Hi Christoph,

On 30.08.2017 15:50, Christoph Berg wrote:
> Re: Ole Streicher 2017-08-30 
>> The idea here is to have just one binary package, containing the shared
>> libraries for all supported versions. Extensions are usually small, so
>> combining them in one package will not hurt. So, there would no
>> "postgresql-9.6-q3c" package anymore, d/control.in is removed, and
>> d/control is fixed (for one release). [...]
> 
> That is true, but it's totally different from what we have been doing
> so far. We would need to update all packages, and providing the
> necessary (?) transitional packages for existing users will be
> difficult.

There is no need to update quickly: if just the dependency variable
creation is integrated in pg_buildext, then the maintainer can still
choose between the current approach and the single-package approach. It
is just a matter of policy then.

Transitioning should just be possible with an additional field

Provides: postgresql-9.6-debconf, postgresql-10.0-debconf [...]

which also could be supported by a variable {postgresql:Provides},
created similarly to {postgresql:Depends} field.

> If a PG version goes out of support, the new package version wouldn't
> contain the module anymore, even if users are still using that PG
> version on their system. (Think Debian dist-upgrades.)

And if a postgresql version goes out of support, then I would suppose
that the postgresql-XX server package is removed as well? Then, they
couldn't upgrade the package because of the missing postgresql
dependency, and they couldn't upgrade in the old scheme.

But I must say I have no idea how upgrades for Postgresql work, there
may be some problems.

> It would also prevent (easily) building packages against beta/devel PG
> versions (10 and 11 at the moment). Or these packages would need to
> include the "normal" PG versions from the normal packages, plus the
> extra versions.

The only difference is that all builds are combined into a single
package. So, whatever can be built in the current scheme, can also be
built then. If "pg_buildext supported-versions" offers experimental
packages, they are also included.

Best regards

Ole


___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Christoph Berg]

Re: Ole Streicher 2017-08-30 
> The idea here is to have just one binary package, containing the shared
> libraries for all supported versions. Extensions are usually small, so
> combining them in one package will not hurt. So, there would no
> "postgresql-9.6-q3c" package anymore, d/control.in is removed, and
> d/control is fixed (for one release). For convenience, I just attach the
> complete d/control for postgresql-q3c.
> 
> In that case, changing the supported postgresql versions will not change
> the list of binary packages, but just the dependencies, which is IMO not
> forbidden.

That is true, but it's totally different from what we have been doing
so far. We would need to update all packages, and providing the
necessary (?) transitional packages for existing users will be
difficult.

If a PG version goes out of support, the new package version wouldn't
contain the module anymore, even if users are still using that PG
version on their system. (Think Debian dist-upgrades.)

It would also prevent (easily) building packages against beta/devel PG
versions (10 and 11 at the moment). Or these packages would need to
include the "normal" PG versions from the normal packages, plus the
extra versions.

The idea is intriguing, though. Maybe these problems have cute
solutions and could be fixed.

Christoph


signature.asc
Description: PGP signature
___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Ole Streicher]

Hi Chriostoph,

On 30.08.2017 14:03, Christoph Berg wrote:
> Re: Ole Streicher 2017-08-30 
>> If a new Postgresql version is uploaded (or an old one is removed), a
>> binNMU can be requested, resulting in a new package with the new list of
>> Postgresql objects built in. As it is done for Python or others.
> 
> BinNMUs would work for updating the ${postgresql:Depends} part. What
> doesn't work is changing the set of binaries built from
> debian/control, because it's forbidden by Debian policy. This is why
> "pg_buildext checkcontrol" raises an error if the file changes.
> Possibly we could make it smarter, but in most cases, changing the
> default version will mean the list of supported versions changes as
> well.

The idea here is to have just one binary package, containing the shared
libraries for all supported versions. Extensions are usually small, so
combining them in one package will not hurt. So, there would no
"postgresql-9.6-q3c" package anymore, d/control.in is removed, and
d/control is fixed (for one release). For convenience, I just attach the
complete d/control for postgresql-q3c.

In that case, changing the supported postgresql versions will not change
the list of binary packages, but just the dependencies, which is IMO not
forbidden.

Best regards

Ole


Source: postgresql-q3c
Section: database
Priority: optional
Maintainer: Debian PostgreSQL Maintainers 

Uploaders: Ole Streicher ,
   Markus Nullmeier 
Build-Depends: debhelper (>= 9),
   postgresql-server-dev-all
Standards-Version: 4.1.0
Homepage: http://www.sai.msu.su/~megera/wiki/SkyPixelization
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-q3c.git
Vcs-Git: https://anonscm.debian.org/cgit/pkg-postgresql/postgresql-q3c.git

Package: postgresql-q3c
Architecture: any
Depends: ${postgresql:Depends},
 ${misc:Depends},
 ${shlibs:Depends}
Description: PostgreSQL extension used for indexing the sky
 Q3C, an extension for PostgreSQL, is designed for the work with large
 astronomical catalogues or any catalogs of objects on the sphere.
 .
 This extension allows a user to perform fast circular, elliptical or
 polygonal searches on the sky as well as fast cross-matches.
 .
 This package provides a module for PostgreSQL.
___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Christoph Berg]

Re: Ole Streicher 2017-08-30 
> For Debian (single Postgresql version) this works well; I don't know
> if "pg_buildext supported-versions" returns them line by line (what I assumed)
> or space-separated (then it needs some adjustments). One should also discuss
> which Postgresql version should be the first (which installed by default).

It's line-separated.

Re the default version, the convention is that
/usr/share/postgresql-common/supported-versions returns the default
version /last/. (Try calling
  PG_SUPPORTED_VERSIONS=pgdg /usr/share/postgresql-common/supported-versions
).

I'm not sure if "pg_buildext supported-versions" preserves that
ordering in all cases; but we can fix it to do so if it's not already
the case. Then there is the question what to do if the default version
is not in the intersection of "debian/pgversions"
`/usr/share/postgresql-common/supported-versions`, which is what
`pg_buildext supported-versions` really computes.

> Ideally the dependency generation could be integrated into pg_buildext.

Right.

> If a new Postgresql version is uploaded (or an old one is removed), a
> binNMU can be requested, resulting in a new package with the new list of
> Postgresql objects built in. As it is done for Python or others.

BinNMUs would work for updating the ${postgresql:Depends} part. What
doesn't work is changing the set of binaries built from
debian/control, because it's forbidden by Debian policy. This is why
"pg_buildext checkcontrol" raises an error if the file changes.
Possibly we could make it smarter, but in most cases, changing the
default version will mean the list of supported versions changes as
well.

Christoph

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Bug#857770: src:postgresql-debversion: please provide a unversioned binary package

[Ole Streicher]

Hi,

maybe I do not fully understand the problem here, but isn't that
solvable easily by changing how d/rules is written? As a first strawman
approach, one could do in d/rules (That is for the upcoming
postgresql-q3c package, which is a very simple one):

---8<--
#!/usr/bin/make -f
# -*- makefile -*-

SRCDIR=$(CURDIR)
PG_VERSIONS=$(shell pg_buildext supported-versions | sort -r | sed 
s/^/postgresql-/)

[...]

override_dh_auto_install:
+pg_buildext install $(SRCDIR) build-%v postgresql-q3c

override_dh_shlibdeps:
dh_shlibdeps
echo "postgresql:Depends=$(PG_VERSIONS)" | sed s/\ /\|/ >> 
debian/postgresql-q3c.substvars

---8<--

The handling of d/control is not needed anymore there (since it is
not generated).

Then, d/control contains:

---8<--
Package: postgresql-q3c
Architecture: any
Depends: ${postgresql:Depends},
 ${misc:Depends},
 ${shlibs:Depends}
Description: PostgreSQL extension used for indexing the sky
 [...]
---8<--

For Debian (single Postgresql version) this works well; I don't know
if "pg_buildext supported-versions" returns them line by line (what I assumed)
or space-separated (then it needs some adjustments). One should also discuss
which Postgresql version should be the first (which installed by default).

Ideally the dependency generation could be integrated into pg_buildext.

If a new Postgresql version is uploaded (or an old one is removed), a
binNMU can be requested, resulting in a new package with the new list of
Postgresql objects built in. As it is done for Python or others.

Is this too short-sighted? Are significant drawbacks here?

Best regards

Ole

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public

Re: [Pkg-postgresql-public] Debian packaging of the q3c and pgsphere extensions

[Christoph Berg]

pgsphere now built successfully on apt.postgresql.org. Even including
PostgreSQL 10 and 11 :)

Christoph

___
Pkg-postgresql-public mailing list
Pkg-postgresql-public@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-postgresql-public