#239 Exception for cxxtest from requiring a devel subpackage
Closed: Fixed None Opened 11 years ago by mgieseki.

= Proposal topic =
Allow the package cxxtest to keep the header files in the base package.

= Overview =
cxxtest is a JUnit-like testing framework for C++ that consists of a bunch of header files and a generation script. The user includes the relevant headers into his test classes and runs the cxxtestgen script on it afterwards. The latter creates the complete code required for the tests to be executed.

During the package review of cxxtest [1] it was suggested to put all files into the base package. Especially, the header files were supposed to go there as well because they are an integral part of the package and can't be reasonably separated from the rest, i.e. cxxtest doesn't work without the header files.

= Problem space =
Recently, the question [2] was brought up whether it's better to provide some kind of -devel package as the guidelines require header files to go into -devel packages. However, the guidelines also mention the exception that plain development packages, like compilers for example, can keep the development files in the base package if a split doesn't make sense.
To me, cxxtest falls into this category too. Thus, I suggest to grant an exception for cxxtest and keep the header files in the base package.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=515463

[2] https://bugzilla.redhat.com/show_bug.cgi?id=888509


No -devel package is required for cxxtest, due to the fact that cxxtest is not useful without headers. The FPC notes that this sort of decision does not really require FPC intervention, as it is considered a package where the split does not make logical sense, and covered by the existing exception. (+1:5, 0:0, -1:0)

The FPC has misunderstood the original suggestion. It was suggested to put all files in cxxtest-devel as the package is a development-only package. It was not suggested to split anything.

Could you please extend the existing guidelines? When to name a package -devel? Currently, static-only libraries are also put into -devel packages.

I suck for not being at the meeting, but I think I agree with Michael, that

  • this should create a cxxtest-devel pkg (following other in-distro examples, like eigen2)

  • i don't follow how existing exception in the guidelines that I find "compilers often include development files in the main package because compilers are themselves only used for software development, thus, a split package model does not make any sense." applies here.

OK, reading things again...

unless the existing exception only uses "compiler" as a specific example of more general case where the "main" package is "only used for software development..."

I guess I can see how that could apply here.

This can get dangerous though... for example, an arch'd package (not the case here, but...) can potentially end up not getting properly multilib'd (if it doesn't provide shlibs nor a -devel subpkg). not sure if it's worth worrying too much about.

This ticket is an unfortunate place where to discuss this further.

It has requested an exception instead of discussing naming issues and the inconsistency that exists in the guidelines currently.

I had hoped that my thread on "packaging" list would have seen at least a single reply, especially because the Wiki suggests that as a place where to discuss something:
https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Discussions

Currently, we MUST store static-only libs in a -devel package, even if there is no base package because there is no run-time package. If one followed today's FPC decision, these files could be placed together with the headers in a base package.

And the guidelines (and misleading example packages in the collection) confuses package submitters. We've had uthash-devel (!) and recently cxxtest because of the guidelines being unclear when to name something -devel.

Question: Do we ever only create -devel packages if there is a package split?

Login to comment on this ticket.

Metadata