Re: Hackathon news - Mailing list pgsql-pkg-debian

Christoph Berg [2012-09-07 17:15 +0200]:
> Afaict, there are two places where supported-versions really matters,
> that is at p-common build time (to determine which PG version
> postgresql.deb should depend on), and extension build time (to
> determine which PG versions to build extensions for). The case where
> the user is notified that he's running an out-of-date versions is not
> so important.

Don't we want to tell people if upstream support for a major version
ceases, and thus apt.p.o. stops distributing packages for that major
version? I think p-common ought to warn about this.

I'm not aware of other situations where it is used.

> > Do you plan to include running the p-common test suite in Jenkins, to
> > ensure that there are no mis-builds or other things we haven't thought
> > of (e. g. a p-common operation that does not work with 8.3)?
>
> That's already up and running,

Splendid!

> The -source script does essentially only add a changelog entry to get
> the version numbers right.

Not sure how much it overlaps, but for backports to my PPA I have this
script:

  http://anonscm.debian.org/loggerhead/pkg-postgresql/postgresql-common/trunk/annotate/head:/debian/backport-ppa

there's a couple of tweaks that one has to do to the packages to make
them build properly in older releases.

> For the server packages (it is also used for extension and general
> packages), it will also move the lib packages (libpq5, libpq-dev,
> ...) to some other component in the archive, except for the current
> stable PG version (beta/rc in unstable).

Yeah, disabling the libraries for older versions is one of the things
my backport-ppa script does; you also need to fiddle with build deps
(at least for the Launchpad builders). But if your setup gets along
with the unmodified packages, so much the better of course.

> This tweak was the reason why I put all those "sid-pgapt" branches on
> bzr.debian.org, but now this tweak is done on the fly. (Which looks
> surprisingly similar to the last patch Martin did on this ppa script.
> I didn't look there before, though :)

Ah, heh :-) Sorry that I didn't point it out before, I tend to forget
about these details once they are properly scripted.

> > The Debian PostgreSQL packages are in bzr. But I'd advise to only
> > build from released versions. To avoid having to wait for the Debian
> > archive processing, how about building packages from tags only,
> > instead of from arbitrary revisions? Then jenkins could watch out for
> > new tags, and immediately get going when it sees one, instead of
> > having to wait for half a day for the Debian archive publisher.
>
> That's the plan, yes. Unfortunately, the Jenkins bzr plugin doesn't
> support that, but as builds are triggered manually at the moment, that
> will work too.

I thought Jenkins supports triggering jobs based on file/URL watches?
So you could put a watch on e. g.

  http://anonscm.debian.org/bzr/bzr/pkg-postgresql/postgresql-9.2/trunk/.bzr/branch/tags

?

> We were discussing this for quite some time, but the issue isn't
> really clear from the notes. The question was: do we pull extension
> packages from unstable, and put them in all our distributions, or do
> we pull the version from the corresponding Debian distribution?

That's a tricky one, and we might need both. E. g. squeeze's version
might support version 8.1 to 8.4, while wheezy's version supports 8.4
to 9.1, or similar. If extensions generally are backwards compatible
as much as we need them, using the unstable packages seems right and
preferrable. We definitively can't use the old packages only, as they
often need porting for newer pg releases.

Thanks,

Martin
--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)