I agree - the files should be in cxxtest-devel instead of the main package.

The guidelines also says:

"There are some notable exceptions to this packaging model, specifically: 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."

In my opinion, cxxtest falls into this category, and therefore no separate -devel subpackage is needed (or even desirable).

I agree with Mattias that this package is a candidate for the mentioned exception, but I could also live with moving everything to -devel. :) Since cxxtest does not work without the header files, everything must be installed together and can't be reasonably split into subpackages in favor of minimizing the install footprint. 
cxxtest is a plain development package, so appending -devel seems kind of misleading to me, as the suffix might suggest there's also a non-devel base package. However, I'm going to ask FPC for clarification.

If only a static library were built, it would also be placed in the -devel package.

[...]

Clarification: I don't suggest splitting off a -devel package. I suggest building *only* a cxx-devel package and treating this like any other software development interface, just that no shared or static library is built. If a library comes with development tools, these are not placed in the run-time base package either, but in the -devel package.

I wonder about the "logical separation", which would be undermined, if the compiler exception example were applied too easily to a growing number of library interface packages (e.g. C++ template class only frameworks, headers with inline implementation). It would also become less easy to find and uninstall optional development-only packages, since queries such as "rpm -qa *-devel" would not find them. Not even mentioning BuildRequires, where one would need to double-check the applied packaging style for any listed non-devel package name.

Installation footprint is not of concern here. Unlike with several hundreds of shared libraries, if the optional thousands of headers were installed automatically.

(In reply to comment #4)
> Clarification: I don't suggest splitting off a -devel package. I suggest
> building *only* a cxx-devel package and treating this like any other
> software development interface, just that no shared or static library is
> built. If a library comes with development tools, these are not placed in
> the run-time base package either, but in the -devel package.

Yes, I got your point and it also seems valid to me. I think the decision to put everything into a devel package or not depends on the paradigm intended by the -devel suffix. If it's used as a tag that allows a quick identification of packages primarily used by developers, then this tag should indeed be used consequently with almost no exceptions. But what about flex, bison, antlr etc. in this case? None of them are devel packages but contain devel files. Also, cxxtest is usually not needed to compile an application and is therefore not required to build a package -- in contrast to library interfaces etc.

Again, you made a valid point. I'm just not sure where to draw the line between packages that must be devel packages and those that don't have to.

> I'm just not sure where to draw the line between packages that
> must be devel packages and those that don't have to.

That's what the guidelines could try to explain. Are "logical separation" and "installation footprint" the only reason for creating -devel packages? Even if the optional headers are just 2KB small? Even if a lib is static only? Or are there other reasons, such as the multilib composer? (cxxtest is noarch)

If the contents of the package match the description in the -devel packaging guidelines, why would I insist on treating the package as an exception? Sure, one packager wants a clear MUST to tell when to create a -devel package, another considers it plausible to create a -devel package because the package contents are pure development files.

Distribution users, who need "flex" for something, install "flex", and the build fails, because sometimes "flex-devel" is needed. For a cxxtest-devel with a virtual cxxtest name that would not be a problem, btw.


When opening this ticket I've posted to packaging list, too. I've not opened a ticket in the FPC tracker, because prior discussion might make that unnecessary.


> quick identification of packages primarily used by developers

Not the primary goal I think. Just a side-effect, but it has been in use for several years. Related: 

/usr/bin/rpmdev-rmdevelrpms

| [...] By default, the following packages are treated as development ones
| and are thus candidates for removal: any package whose name matches
| "-devel\\b", "-debuginfo\\b", "-sdk\\b", or "-static\\b" (case
| insensitively) except gcc requirements; any package whose name starts
| with "perl-(Devel|ExtUtils|Test)-"; [...]

And the list of exceptions hardcoded in that script is not too long [yet].


> But what about flex, bison, antlr 

Well, flex-devel and bison-devel _do_ exist. Even an extra bison-runtime package, although nothing depends on it.

Related to this is some arbitrariness and historical reasons. (automake, make, libtool, …)

These as well as several similar ones are development tools/programs, typically in RPM Group Development/Tools. Some of them have been packaged many years ago in a single package when the goal was to get the software packaged as it was needed. With no concerns about "installation footprint". Meanwhile, there are run-time dependencies on those packages, however:

$ repoquery --exactdeps --whatrequires flex|wc -l
8
$ repoquery --exactdeps --whatrequires bison|wc -l
5
$ repoquery --exactdeps --whatrequires bison-runtime|wc -l
0  <-- (!)
$ repoquery --exactdeps --whatrequires make|wc -l
21

There are also GUI designer tools, which are development-only programs, and they are treated like ordinary application packages.

Some are corner-cases. What about m4 and pkgconfig? When is a tool development-only? On the contrary, gettext, gettext-libs and gettext-devel, with a three package split because of run-time libs, API and optional development tools.


> cxxtest is usually not needed to compile an application and
> is therefore not required to build a package -- in contrast
> to library interfaces etc.

If the test suite is built by default, the cxxtest headers become a strict build requirement. If the test suite is built only if enabled explicitly in a Fedora spec file, the cxxtest headers also becomes a build requirement. If the programmer decides to include tests into the normal implementation, the cxxtest headers will be strictly needed and generated code my need to be regenerated for compatibility reasons. What's left? A single Python script cxxtestgen, which is needed only when generating test source code from the cxxtest .cpp/.h files.

So, this is very much like an ordinary -devel package (e.g. cpptest-devel, cppunit-devel), just that there is no shared or static library. The library code is shipped as .cpp files in /usr/include/cxxtest/, which are _copied_ into generated source code which needs to be compiled and which may be linked into a built package.

I close this as NOTABUG, because there is no serious interest in understanding the issue, and the opened FPC ticket also requested an exception to be granted instead of discussing this in an attempt to improve the packaging guidelines. I think this is short-sighted.

Sorry for the trouble in case you considered this as troublesome!

Michael, I'm sorry if this whole thing didn't ended up the way you would have preferred it. I neither intended to annoy you nor did I consider this topic troublesome in any way. At least I think, I always try to be a cooperative person. Therefore, I'm a bit irritated by the direction this discussion took. Not to mention the kind of taunting tone in your latest comments. 

FYI, I'm currently knocked down by the flu, and thus work only in basic mode. Maybe that's why I didn't get the whole picture of the point you was trying to make. When I noticed this ticket, I thought: "He's making a valid point. Let's see what the guidelines say about it." Unfortunately, the guidelines are not very clear in what cases packages like cxxtest must be devel packages. Currently you find reasons for both alternatives in them. That's why I thought it was a good idea to ask the FPC people about it, as suggested by the guidelines as well. BTW, you mentioned the FPC in your initial post too.
Obviously, you'd rather discussed the topic on the packaging list and left FPC out initially. Fair enough but I didn't know. Unfortunately, your corresponding post there slipped through my radar. Sorry for that.

As the question when to require devel packages and when they are optional seems to be a fundamental one, it should still be discussed on the packaging list. I'm happy to participate as soon as I'm healthy again.

If you see "taunting tone" I don't know where and would like to learn where.

When I wrote "Sorry for the trouble..." this was honest, because after I had seen the opened FPC ticket it has become clear that you would rather want to keep the cxxtest naming, insist on treating this package like a compiler package, and be done with it. Or else you would _not_ have requested an exception to be granted, and you would _not_ have talked about a split or a subpackage, which hasn't been suggested in this ticket.

[...]

> BTW, you mentioned the FPC in your initial post too.

Of course. The linked package review request reveals an initial cxxtest-devel package, later the rpmlint warning has been ignored, but the ticket doesn't tell whether the FPC has been consulted. It sounds wrong to treat arbitrary header packages like a compiler package.


Obviously I'm disappointed that nobody has commented on the mailing list (the FPC explicitly points out that "discussion and decisions can also take place on the mailing list": https://fedoraproject.org/wiki/Packaging_Committee#Discussions ) and that the FPC ticket has been handled like a hot potatoe. Perhaps because the ticket is misleading. This bug is linked, however, but the brief FPC ruling talks about a split and doesn't even acknowledge that the guidelines could be improved. There are already src.rpm packages, which are named *-devel because of the unclear guidelines. This isn't good, for some packages it isn't future-proof either. For the moment I'm somewhat discouraged by the desinterest, however, to even think about how to get through to the FPC and meet serious interest.

(In reply to comment #9)
> There are already src.rpm packages, which are named *-devel
> because of the unclear guidelines. This isn't good, for some packages it
> isn't future-proof either. For the moment I'm somewhat discouraged by the
> desinterest, however, to even think about how to get through to the FPC and
> meet serious interest.

Pray tell any examples of this...

* inih-devel and uthash-devel Review Requests off the top of my head. Preferably, the package submitters would tell which sections of the guidelines have lead to this. And there's a risk that a reviewer doesn't disagree.

[...]

Counter-examples _in_ the package collection, which have not been treated like a compiler package:

* libkdtree++ builds a library-less libkdtree++-devel package. Noarch, too.

* eigen3, eigen2 are also C++ Template "Libraries", which build a library-less noarch -devel package.

* glm builds a library-less -devel package. Not noarch, however.

The same question arises for Boost as well. So, I am interest by the outcome of the discussion... if any takes place at all.

Personally, I prefer Michael's proposition (as I understand it), i.e., putting header files in a dedicated -devel package, even if that means having a virtual core package.

Then, I do have a question in the case of Boost sub-packages (e.g. boost-date-time): should we have move them as -devel sub-sub-packages (e.g., boost-date-time-devel)?