On 18/09/16 20:35, Steve M. Robbins wrote:
On Sunday, September 18, 2016 10:51:16 AM CDT Ghislain Vaillant wrote:

 > but it is in conflict with the well-established standard way
 > of how libraries are distributed in Debian.

This is incorrect. Header-only libraries are present in the Debian
archive, such as libboost-dev or libeigen3-dev. A -dev package does
not automatically have an accompanying shlib package.

True.  But as Joachim later pointed out: -dev packages do typically provide a
ready-to-use library -- whether it be header-only or accompanied (by
dependency) with link libraries.

In fact, we did previously distribute a compiled Google Test -- until I came
across the upstream recommendation to not do so.   So in the past, the name
libgtest-dev was much more in keeping with traditional practices.

In hindsight, I probably should have just changed the package name.  But at
the very least it could be more clearly labelled.  I agree with that much and
I do apologize for not acting on this bug report.

I don't see what you could have done more. There is a NEWS file
explaining the change and the description of the package reflects what
it contains.

This has nothing to do with libgtest-dev being deceptive, but with you
failing to understand how modern integration of GTest with CMake is
supposed to happen in accordance with upstream recommendations.

I don't think there's any need to call out perceived personal failings.

Perhaps, but calling your work "deceptive" made by eyebrows raise a
little. Here, the obvious failing here is the lack of information gathering from OP regarding modern usage of gtest.

Modern integration uses ExternalProject_Add to fetch the gtest source,

I did not know about this technique, so I learned something.  Thanks!

Glad to help.

Moving forward, did you have a chance to look at #835487?

Since both gmock and gtest have merged as googletest, and a new
upstream release is here, perhaps now is the best time to introduce a
new source package with an appropriate name (googletest), producing a
binary package with a less "deceptive" name (googletest), and provide
the appropriate transitional packages for the old gtest and gmock.

Otherwise we'll just end-up with duplication between the gmock and
gtest source package. Thoughts?


Reply via email to