Debian packaging

[anayrat]

Should address #21 (cc @df7cb)

Be gentle, I am not used to Debian packaging. I based it on other extensions and how packaging was done for rum : https://salsa.debian.org/postgresql/postgresql-rum/-/tree/debian/

I put myself has maintainer as we must provide email and I did not know which one we should use. I not sure if it is the right way to do.

I also note the Licence is not exactly the same in rum package than in the repo :
https://salsa.debian.org/postgresql/postgresql-rum/-/blob/debian/LICENSE
https://salsa.debian.org/postgresql/postgresql-rum/-/blob/debian/debian/copyright

For the last, I did not know how to run debian's test? I followed the same logic as https://github.com/powa-team/powa-archivist/blob/master/debian/tests/installcheck

While testing it seems there is something weird between latest release 1.1.1 while EXTVERSION says 1.1 in Makefile https://github.com/postgrespro/pg_wait_sampling/blob/master/Makefile#L7 Fixed

[ololobus]

Hi @anayrat, thank you for your contribution!

Be gentle, I am not used to Debian packaging. I based it on other extensions and how packaging was done for rum

Same here, so some readme file debian/README.md with explanation of how it all is intended to be used is very welcome. Probably it should just say run make deb and that's all, but anyway. Maybe some dependencies? E.g. Makefile uses unzip which may be absent on some distros by default, IIRC.

While testing it seems there is something weird between latest release 1.1.1 while EXTVERSION says 1.1 in Makefile https://github.com/postgrespro/pg_wait_sampling/blob/master/Makefile#L7

Maybe we were wrong, but it was done intentionally, since Postgres requires an *.sql update file if default_version in the control file has changed. So we reserved a third number in the release number for releases, that only touch C code part. Both 1.1 and 1.1.1 are basically the same from the Postgres perspective and will look like 1.1 in the pg_extension, but the last number is used to indicate that it is still a different release. That way, it seems to better use 1.1.1 for a deb package.

Maybe it is rather misleading than useful and we should simply create empty sql update scripts for such minor releases in the future?

[anayrat]

Hi @anayrat, thank you for your contribution!

Be gentle, I am not used to Debian packaging. I based it on other extensions and how packaging was done for rum

Same here, so some readme file debian/README.md with explanation of how it all is intended to be used is very welcome. Probably it should just say run make deb and that's all, but anyway. Maybe some dependencies? E.g. Makefile uses unzip which may be absent on some distros by default, IIRC.

Yes, I will change that.

While testing it seems there is something weird between latest release 1.1.1 while EXTVERSION says 1.1 in Makefile https://github.com/postgrespro/pg_wait_sampling/blob/master/Makefile#L7

Maybe we were wrong, but it was done intentionally, since Postgres requires an *.sql update file if default_version in the control file has changed. So we reserved a third number in the release number for releases, that only touch C code part. Both 1.1 and 1.1.1 are basically the same from the Postgres perspective and will look like 1.1 in the pg_extension, but the last number is used to indicate that it is still a different release. That way, it seems to better use 1.1.1 for a deb package.

Maybe it is rather misleading than useful and we should simply create empty sql update scripts for such minor releases in the future?

That was a mistake of my part. Version is obtained from changelog https://github.com/postgrespro/pg_wait_sampling/pull/23/files#diff-45c17c0a080fbe29e2b8ded8940aa1e8R1
I add to change 1.1.1 to 1.1-1. I have seen other project doing like that. I was able to build package and install it on debian stretch.

[df7cb]

Hi,
the debian/ dir looks mostly good. A few comments:

• none of the "release-zip", "deb", or debian/rules "orig" targets are required, and in fact, they won't be used by the (official) package builds. The entry point is dpkg-buildpackage (or some variant like debuild).
• is the dependency on postgresql-contrib-PGVERSION required?
• the current Standards-Version is 4.5.0 (debian-policy)
• better use 3.0 (quilt) in debian/source/format. (I was using 1.0 for some time to make building from git easier, but the better fix for that problem is dpkg-buildpackage -b.)
• remove debian/tests/control.in, it doesn't have any placeholders, debian/tests/control is enough

On the questions upthread:

• to run the tests, use autopkgtest. (But in practise, you don't need the extra machinery and could just invoke the debian/tests/installcheck script directly)
• the syntax is the test script is wrong, correct would be -o "shared_preload_libraries=pg_wait_sampling" (without the spaces around = and the extra 'quotes')
• a dependency on zip is not required as it's not being used for the build process
• re 1.1 vs 1.1.1: It's actually a very good idea to decouple the release version from the SQL extension version. That way, you can release new code versions without having to bump the SQL version all the time (meaning you have to change Makefile, write a new --version.sql file, and all users have to do the ALTER EXTENSION .... UPDATE dance without an actual change on that level).
  As the actual release version is 1.1.1, change the Debian version to 1.1.1-1.

I already added a build job on apt.postgresql.org (which fails because of the wrong version), but we are actually pretty close to get this going. Thanks for working on this!

https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/

[anayrat]

Hi,
the debian/ dir looks mostly good. A few comments:

* none of the "release-zip", "deb", or debian/rules "orig" targets are required, and in fact, they won't be used by the (official) package builds. The entry point is dpkg-buildpackage (or some variant like debuild).

Ok, I will remove them.

* is the dependency on postgresql-contrib-PGVERSION required?

I don't think contrib are necessary.

* the current Standards-Version is 4.5.0 (debian-policy)

Fixed

* better use `3.0 (quilt)` in debian/source/format. (I was using 1.0 for some time to make building from git easier, but the better fix for that problem is dpkg-buildpackage -b.)

Fixed

* remove debian/tests/control.in, it doesn't have any placeholders, debian/tests/control is enough

Fixed

On the questions upthread:

* to run the tests, use `autopkgtest`. (But in practise, you don't need the extra machinery and could just invoke the `debian/tests/installcheck` script directly)

* the syntax is the test script is wrong, correct would be `-o "shared_preload_libraries=pg_wait_sampling"` (without the spaces around = and the extra 'quotes')

Fixed

* a dependency on zip is not required as it's not being used for the build process

* re 1.1 vs 1.1.1: It's actually a very good idea to decouple the release version from the SQL extension version. That way, you can release new code versions without having to bump the SQL version all the time (meaning you have to change Makefile, write a new --version.sql file, and all users have to do the ALTER EXTENSION .... UPDATE dance without an actual change on that level).
  As the actual release version is 1.1.1, change the Debian version to 1.1.1-1.

Fixed

I already added a build job on apt.postgresql.org (which fails because of the wrong version), but we are actually pretty close to get this going. Thanks for working on this!

https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/

[anayrat]

I noticed I forgot to remove mention of postgres-contrib. It should be fine now. I tested with debuild -b -uc -us and ran ./debian/tests/installcheck.

[anayrat]

I don't know why travis test is queued but it seems not related to this PR?

[ololobus]

@anayrat, yep, and it has even passed CI [1]. I do not know why the status of PR has not been updated. Anyway, you are right, there is nothing to check in this PR from the CI perspective.

I thought that we were just waiting a feedback from @df7cb confirming that packaging worked fine. However, I see that Jenkins build job [2] has not been retried after your latest changes and it is still marked as 'failed'.

Should I merge PR first to make package build working?

[1] https://travis-ci.com/github/postgrespro/pg_wait_sampling/builds/172812004
[2] https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/

[df7cb]

Sorry for the non-feedback, I'm currently on vacation and won't take this up again until around July 14th.

[df7cb]

One last minor bit, then we are good to go:
In debian/watch, the pattern for releases is wrong, it should be v instead of REL:

version=3
opts="uversionmangle=s/_/./g" \
  https://github.com/postgrespro/pg_wait_sampling/releases .*/archive/v(.*).tar.gz

Then you can set the distribution to unstable in debian/changelog (use dch -r).

[anayrat]

@df7cb it should be ok now :) thanks.

[anayrat]

@df7cb is it possible to trigger a new rebuild on https://pgdgbuild.dus.dg-i.net/job/pg-wait-sampling/ ? Thanks!

[anayrat]

@df7cb as I can see packages seems presents on http://apt.postgresql.org/pub/repos/apt/pool/main/p/pg-wait-sampling/
But they does not appear if I search them with apt search ... Do I miss something?

[df7cb]

As you can see from the weird version number, these aren't release builds but some intermediate test build product. The packages are available if you add dist-pgdg-testing to your sources.list only.

[df7cb]

I just triggered a real build, packages will be on the mirrors in about an hour.

👍 on merging this now.

[anayrat]

@ololobus ça we merge this pr? Thanks

[ololobus]

Merged. Thanks @anayrat and @df7cb. Let me know if any additional changes will be required.