Re: Redis & SQLite FDW packages - Mailing list pgsql-pkg-debian

Hi Michel,

I have provided a some detailed comments about the files under debian/
below. However, as a high-level comment I am somewhat confused about the
layout of the repository. It looks like have both the unpacked source
package form and the original upstream source are being tracked in the
same repo. I know that it is mentioned that this is possible in the
postgresql-debian-packaging [1] documentation but I don't think I have
seen this done of additional tooling like gbp [2] which it doesn't look
like is the case here. When I attempt to build the package using either
sbuild or dpkg-buildpackge, it complains that no upstream tarball can be
found. What I've seen most commonly with packages maintained by the
Debian PostgreSQL Maintainers is that unpacked source format only is
maintained in a separate git repo (usually hosted on salsa.debian.org).
As a concrete example, the source package for pgvector is maintained at
https://salsa.debian.org/postgresql/pgvector and it only contains the
content of the debian/ directory. The upstream source tar archive is
downloaded from the GitHub repo for pgvector
https://github.com/pgvector/pgvector. This downloading can be done
wither manually or with uscan.

Assuming the desired end-goal is that the sqlite_fdw is available for
download and installation from the PGDG archive for all supported
versions of PostgreSQL, these are the steps that need to be done:

1. File an intent-to-package (ITP) bug [3] with bugs.debian.org
    * This will be the source of the bug number that will be referenced
      in the d/changelog line "Initial release. (Closes: #XXXXXX)"
2. Set up a Git repo on salsa.debian.org for maintaining the unpacked
   source package form and get that passing Salsa's standard CI/CD
   pipeline
    * Most the work creating the unpacked source package form is done
      and hosting on s.d.o is not strictly required but follows the
      convention most other PostgreSQL packages are following. Passing
      Salsa's standard CI/CD pipeline will give a good indication of
      whether the package will successfully upload to the Debian archive
3. Add configuration to pgapt [4] to configure the PGDG archive to
   build and publish the package for all supported Debian/Ubuntu
   distributions and all supported PostgreSQL versions


1. d/NEWS
    * You do not need the asterisk per [5]
2. d/changelog
    * should be UNRELEASED since the package has not been uploaded to
      the Debian archive yet. In my experience as a non-uploading team
      member, this is changed to unstable when the uploader uploads to
      the archive. It is set to unstable because that's the distribution
      that the upload is going to; it will automatically enter testing
      based on a set of criteria outlined in [6]. These terms are
      referring to the Debian distribution and not a reflection of the
      state of the upstream project. When the package is re-uploaded to
      the PGDG repos, a new changelog entry will be automatically
      appended with the appropriate distribution substituted.

    * The content of d/changelog is the changelog for the Debian source
      package not the upstream project -- I would not include content
      from any of the releases prior to the initial release version but
      this is my opinion/preference and not hard technical requirement.

3. d/control
    * The Maintainer field  should be set to the package maintainer's
      name and email address [7]
    * The Maintainer field is currently just as "Taiga Katayama" but
      this field is intended for the individual(s) who are maintaining
      the Debian package, not necessarily the upstream maintainer. This
      could either be set to yourself or to the Debian PostgreSQL
      Maintainers. Either way, you will most likely need to also include
      an Uploaders field which includes the name and email address of a
      uploader. [8]
    * There should only be one binary package for PostgreSQL 17 listed
      in d/control. The Debian archive only has one version of the
      PostgreSQL server packages available which for unstable is
      currently 17. Including the other versions and their build
      dependencies in the source package will fail to build when
      uploading to the archive. The archive hosted at PGDG will use
      d/control.in to re-build the package for all PostgreSQL versions
      available in the PGDG archive.
4. d/copyright
    * I am unsure about the use of 'PostgreSQL_like' in the License
      field. My overly cautious reading of [9] indicates that this field
      should use a standard short name and this name is not referenced
      in either [9] or [10]. Based on a quick reading of [11], I think
      the short name should be either 'PostgreSQL License' or
      'PostgreSQL'. However, I am not an expert on copyright matters and
      this is my opinion informed by the referenced links.

5. d/tests
    * I anticipate that the autopkgtests will fail as-is when building
      the packages on PGDG because of the hard-coding of the minor
      version in the paths to the SQL queries. I have a patch that uses
      wildcards to match the PostgreSQL major version to the appropriate
      tests.


[1]: https://salsa.debian.org/postgresql/postgresql-common/-/blob/master/doc/postgresql-debian-packaging.md
[2]: https://wiki.debian.org/PackagingWithGit
[3]: https://wiki.debian.org/ITP
[4]: https://git.postgresql.org/gitweb/?p=pgapt.git;a=summary
[5]:
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#supplementing-changelogs-with-news-debian-files
[6]: https://wiki.debian.org/DebianTesting
[7]: https://www.debian.org/doc/debian-policy/ch-controlfields.html#maintainer
[8]: https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
[9]: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name
[10]: https://spdx.org/licenses/
[11]: https://spdx.org/licenses/PostgreSQL.html