Bug#989344: ogre-1.12: diff for NMU version 1.12.10+dfsg2-1.1

[Simon McVittie]

On Sun, 13 Jun 2021 at 21:39:48 -0400, Olek Wojnar wrote:
>     After bullseye is released, next time upstream bumps the SONAME
>     (presumably 1.12.12?), I think it would be good to seriously consider
>     packaging the libraries as libogremain1.12.12, libogreoverlay1.12.12
>     and so on.
> 
> My perspective on that is if the libraries are all meant to be used together
> then it makes little sense to split them into separate packages. That being
> said, I'm not 100% that this is the case with OGRE. If not, your suggestion
> would certainly make the packaging cleaner, if more lengthy. My other concern
> is that I don't want to force dependent packages to declare 20 dependencies.

If you leave the -dev package as a single monolithic binary package, then
maintainers of dependent packages shouldn't need to change anything: they
still declare Build-Depends: libogre-1.12-dev, and then their
${shlibs:Depends} expands to something like
"libogremain1.12.12 (>= x), libogreoverlay1.12.12 (>= y)" depending which
ones they are linked to.

For example, Pango now works like this: we still only have one -dev
package to Build-Depend on, libpango1.0-dev. Depending on which parts
you actually use, you might get runtime dependencies on libpango-1.0-0,
libpangocairo-1.0-0, libpangoft2-1.0-0 and/or libpangoxft-1.0-0.
Qt is another good example of this approach: qtbase5-dev is the -dev
package for libqt5core5a, libqt5gui5 and various others.

Having one -dev package per shared library is not required, although
some maintainers prefer to do it anyway for consistency (for example
libpolkit-agent-1-dev and libpolkit-gobject-1-dev are separate,
but arguably they could equally well have been combined). The time it
becomes important to split -dev packages is when they have relatively
"heavy" dependencies, for example in the poppler source package, which
has separate -dev packages for the core library, the generic C++ binding,
the GLib binding and the Qt binding.

If I'm packaging a multi-library package from scratch, and the upstream
project is already neatly split up by shared library with separate
header directories and pkg-config .pc modules (like Pango is, and like
Ogre seems to be), then I would personally split the -dev package - but
that's personal opinion and not a Policy requirement. If I'm updating an
existing package, I won't usually split a monolithic -dev package unless
there's a specific reason to need to do it, which is why I didn't split
libpango1.0-dev.

> Organizing the package contents to not waste
> archive space is definitely a good thing to add to the list of things to
> address next.

This isn't actually about (not) wasting archive space, it's about whether
two different SONAMEs of the same library can be installed in parallel
(like the way you could install both libssl1.0.2 and libssl1.1 on Debian
9 systems, and in practice often had to do so during upgrades). Not
wasting archive space by introducing an Architecture: all package for
data is just a nice side-effect.

    smcv