On Thu, 06 May 2021 at 00:11:37 +0100, Christian Rauch wrote:
> I am already maintaining an Ubuntu ppa at:
> https://launchpad.net/~christianrauch/+archive/ubuntu/libdecoration
> but would like to upstream the package into Debian.
Is the packaging you used in that Ubuntu PPA already available as a
git tree?
> Since this is my first time packaging a library for Debian, I could use
> support from a co-maintainer who is familiar with Wayland
More important would be to have a co-maintainer who is familiar with
packaging shared libraries, I think. There are some subtleties that are
important to get right.
It would probably make sense for the SDL team and/or the GNOME team to
be in Maintainer and/or Uploaders for this package - SDL wants to use it,
and it comes from GNOME infrastructure and uses GNOME-adjacent libraries
and coding conventions. I'm in both teams and would be willing to
co-maintain. I can help to implement the suggestions below, or you
could do them, whichever you'd prefer.
I haven't yet reviewed the upstream code at all (except for the build
system MR), but a Debian Developer will need to do that before upload,
to check for legality/licensing issues and make sure the code isn't
malicious or obviously broken (I'm sure it isn't, but someone should check).
Some quick review of the version from the PPA:
Package naming:
- Source package name should be libdecor-0 now that upstream has
co-installable naming conventions
- libdecor binary package should be renamed libdecor-0-0 to match the
SONAME libdecor-0.so.0, with Conflicts: libdecor, Replaces: libdecor
to avoid conflicts with the unofficial PPA package
- libdecor-dev binary package should be renamed libdecor-0-dev to match
the .pc file, with Conflicts: libdecor-dev, Replaces: libdecor-dev
- libdecor-plugin-cairo should maybe be renamed libdecor-plugin-1-cairo
or something, to reflect plugin_api_version
d/control:
- libdecor dependency on libwayland-client0 should be unnecessary, you
should find that ${shlibs:Depends} adds a suitable dependency
- Similarly libdecor-plugin-cairo dependency on libcairo2 and
libpangocairo-1.0-0 should come from ${shlibs:Depends}
- libdecor-plugin-cairo should probably have Provides: libdecor-plugin-1
- libdecor-0-0 should probably have
Recommends: libdecor-plugin-1-cairo | libdecor-plugin-1
so that third-party plugins (if any) can Provides: libdecor-plugin-1
- The Standards-Version is very out of date, please check that the package
follows current Debian Policy and then set it to the current Policy
version (4.5.1 at time of writing)
- libdecor-plugin-cairo needs a long Description
d/compat:
- Please use the recommended debhelper compat level (13) for new packages,
unless there is a very good reason to require an older compat level.
The preferred way to do this is to add
Build-Depends: debhelper-compat (= 13) and delete d/compat.
d/copyright:
- The version of the MIT/X11 license quoted here is called "Expat" in
d/copyright files, to distinguish it from the many other licenses
used by MIT and X11.
- You can probably use
Files: *
Copyright: (the same as you have now)
License: Expat
on the assumption that .gitignore, README, meson.build, etc. have the
same copyright holders and licensing as the rest of the package.
- Please declare a copyright holder (you or your employer) and a license
(probably Expat) for the debian directory.
- The copyright file isn't following copyright-format 1.0 syntax yet.
Please see the python3-vdf package (which I maintain) for an example of
a copyright file for a package with the same license as this one.
d/README.Debian:
- If you don't have anything to say here, please delete it
d/rules:
- Probably best to remove the commented-out stuff
- I would suggest enabling the demos and installing them in a new
libdecor-tests package - otherwise it'll be hard to do manual testing
on this package without having the patched SDL available. This will
need some extra build-dependencies.
If this package later gains automated tests, the libdecor-tests package
could contain those too.
Ideally the libdecor-tests package would have Build-Profiles: <!noinsttests>
(I can help with this).
d/source/format:
- Should be 3.0 (quilt) instead of 3.0 (native) for a package with an
upstream developer outside Debian
d/git-build-recipe.manifest:
- This should be removed for an official Debian package.
Other:
- There should be a debian/watch to download the latest official upstream
release. If upstream doesn't release tarballs then use something similar
to
https://salsa.debian.org/gnome-team/gnome-desktop-testing/-/blob/debian/2018.1+git20210629-1/debian/watch
to download it directly from git.
- I think all shared library packages should have at least a superficial
autopkgtest, for example similar to the ones in
<https://salsa.debian.org/utopia-team/pipewire/-/blob/debian/master/debian/tests/libpipewire-0.3-dev>
or <https://salsa.debian.org/sdl-team/libsdl2-ttf>.
