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

[Olek Wojnar]

Hi smcv,

On Sun, Jun 13, 2021 at 6:43 PM Simon McVittie <smcv at debian.org> wrote:

>
> On Sun, 13 Jun 2021 at 22:18:42 +0200, Jochen Sprickerhof wrote:
> > * Olek Wojnar <olek at debian.org> [2021-06-13 15:15]:
>
> some API designs make it
> really hard to keep backwards compatibility, because a lot of internal
> decisions get exposed as API/ABI. This is particularly likely to happen
> if the way the upstream developer expects their library to be used and the
> way we expect libraries to be used don't match, which is somewhat common
> in games particularly


True, good point. And those are a very common user of OGRE.


> The shared-library parts
> of Policy (section 8) are there for good reasons, and I would recommend
> checking that you understand those sections if you're maintaining or
> sponsoring a shared library package. Others on the debian-devel-games
> mailing list can help if you are unsure.
>

Before this, I would have said that I'm quite comfortable with packaging
libraries. I guess we're all always learning. And I'm clearly due for a
re-read of that section. ;)


> 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. Either way though, I appreciate the suggestion! It's a
very good point and worth investigating. I'll definitely have that
conversation with Simon (Schmeisser) when we discuss that packaging for
1.12.12.


> If that isn't an option (for example if the ftp team reject that version
> from NEW saying that the binary packages are too numerous / too small),
> then I would recommend having some automatic checks in the packaging
> that will make sure the package fails to build if the SONAME is not what
> we expect, for example by running an implementation of this pseudocode
>

Thanks for the pseudocode, and for the suggestion! Yes, that definitely
sounds like a very smart idea if we end up not splitting the packages.


> Better to catch this sort of thing *before* upload, after all!
>

+100


> Again, that seems like something that would be good to fix post-bullseye.
> The upstream SONAME bump will need to go through NEW *anyway*, so it's a
> good time to add a libogre-data package.
>

Good point. Simon and I have been working on cleaning up quite a few issues
in the package and, thus far, the focus has been on the most critical (i.e.
Lintian Errors and Warning). Organizing the package contents to not waste
archive space is definitely a good thing to add to the list of things to
address next.

(If the non-library resource files were in /usr/share/OGRE-1.12.12 then
> it would be OK for them to stay with the library.)
>

I think your first suggestion is the better solution. And if something
needs to be changed, I very much believe in changing it the right way from
the start! :)

-Olek