Dear Maintainer,

Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the binary packages
do not follow the layout for libraries that is described in Policy Section 8.
For instance I think we should provide a shared library and if there are enough
reasons not to do so (see Policy 8.3), at least the binary package name should
be changed to libcatch2-dev.

Also this is not a header-only library anymore, the description of the package
should be changed.

As a side note, the upload of the major version 3.x came out with many breaking
interface changes giving rise to RC bugs in e.g. genomicsdb, netgen, spdlog,
therion just to name a few, also to failing autopkgtests in many rdeps. I would
have been more comfortable with such a huge version change being advertised and
more prepared, with some kind of a library transition process for instance.

In any case, thanks for your work on catch2,

Best regards,

Hello,

I agree, binary package could be renamed and descriptions should be
adapted as well. I am not sure about shared library, though.

First, upstream uses full source package version for soversion. This
means a transition for even a patch level upstream release. I maintain a
couple of packages like this and it is tiring.

Second, I do not expect any real binary package depending on catch2
shared library as only test objects are linked with it. But I may be
wrong here.

Right. Such changes should be announced beforehand since catch2 is used
widely in the archive. Transition would have been nice indeed.

Seconded - thanks for maintaining this package.

Best wishes,
Andrius

Hi,

Thanks Andrius for the advice given here.

On Wed, 8 Nov 2023 09:44:58 +0200 Andrius Merkys <merkys@debian.org> wrote:
 > Hello,
 >
 > On Thu, 02 Nov 2023 18:10:19 +0100 Pierre Gruet <pgt@debian.org> wrote:
 > > Recently catch2/3.4.0-1 was uploaded to Debian, great. Yet the
binary packages
 > > do not follow the layout for libraries that is described in Policy
Section 8.
 > > For instance I think we should provide a shared library and if
there are enough
 > > reasons not to do so (see Policy 8.3), at least the binary package
name should
 > > be changed to libcatch2-dev.
 > >
 > > Also this is not a header-only library anymore, the description of
the package
 > > should be changed.
 >
 > I agree, binary package could be renamed and descriptions should be
 > adapted as well. I am not sure about shared library, though.
 >
 > First, upstream uses full source package version for soversion. This
 > means a transition for even a patch level upstream release. I maintain a
 > couple of packages like this and it is tiring.
 >
 > Second, I do not expect any real binary package depending on catch2
 > shared library as only test objects are linked with it. But I may be
 > wrong here.

This seems like a good reason to keep a static library, at least for the
moment.

If there remains only the renaming of the package and its description to
be changed, then downgrading the severity looks sensible.

 >
 > > As a side note, the upload of the major version 3.x came out with
many breaking
 > > interface changes giving rise to RC bugs in e.g. genomicsdb,
netgen, spdlog,
 > > therion just to name a few, also to failing autopkgtests in many
rdeps. I would
 > > have been more comfortable with such a huge version change being
advertised and
 > > more prepared, with some kind of a library transition process for
instance.
 >
 > Right. Such changes should be announced beforehand since catch2 is used
 > widely in the archive. Transition would have been nice indeed.

If you, Mathieu, have some insight into the best ways to transition
reverse dependencies, I think giving it in the related bug reports would
be very helpful.

 >
 > > In any case, thanks for your work on catch2,
 >
 > Seconded - thanks for maintaining this package.
 >
 > Best wishes,
 > Andrius
 >
 >

Have a great day,

Hi,

Thanks both of you for the feedback. I'm short on time at the moment
but I'll make the changes you suggested, they makes sense.

And sorry for pushing this version without notice, I didn't realise
other packages were using it and depended on its API.

Cheers.

Mathieu.

On Wed, 8 Nov 2023 09:57:39 +0100 Pierre Gruet <pgt@debian.org> wrote:

 > Control: severity -1 important
 >

 > This seems like a good reason to keep a static library, at least for the
 > moment.
 >
 > If there remains only the renaming of the package and its description to
 > be changed, then downgrading the severity looks sensible.
 >
 > >
 > > > As a side note, the upload of the major version 3.x came out with
 > many breaking
 > > > interface changes giving rise to RC bugs in e.g. genomicsdb,
 > netgen, spdlog,
 > > > therion just to name a few, also to failing autopkgtests in many
 > rdeps. I would
 > > > have been more comfortable with such a huge version change being
 > advertised and
 > > > more prepared, with some kind of a library transition process for

 > instance.

Should there maybe a new src:catch2 package be provided ? This also
broke tests for trompeloeil-cpp which I maintain.

This seems like a sensible solution for now. according to upstream notes
catch/catch2.hpp is superseded by catch/catch2_all.hpp,

but liking against this header does not work for my package (see
https://github.com/catchorg/Catch2/blob/devel/docs/migrate-v2-to-v3.md).

I'd propose to check which packages work with the newer catch and patch
if necessary; if it's inevitable I'd argue to create a semver catch2
package.

best,

 > And sorry for pushing this version without notice, I didn't realise
 > other packages were using it and depended on its API.

really? what do you expect when uploading that to the archive?

   reverse-depends -b src:catch2

tells you all it's users.

gringo seems to broken as well: https://bugs.debian.org/1054688

Hello,

Trying to make an internal build for a user with a possible bugfix, I noted that recent libcatch2-dev
dependency was not built for i386 (and presumably other platforms like s390x), creating an
immediate B-D failure on `apt-get build-dep kodi` on i386. Installing catch2 version 3.4.0 from trixie
lets me build Kodi just fine.