No -devel package

[Michael Schwendt]

https://bugzilla.redhat.com/888509 : "No -devel package"

This has been filed for package "cxxtest" because of:
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages

Comments appreciated.

[Michael Schwendt]

> https://bugzilla.redhat.com/888509 : "No -devel package"
>
> This has been filed for package "cxxtest" because of:
> https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
>
> Comments appreciated.

Dear packager,

instead of spending a minute on a nice reply here on the list, the FPC
ruled quickly on something related today because a ticket has been opened
in parallel. You may continue to store all these development-only files in
the base package instead of building only a -devel package. Now pray that
the packaged software will never add a library. Because then you would
need to change any BuildRequires for your package in other spec files.

[Michael Schwendt]

[a mail each day keeps the doctor away]

Copying from bugzilla for public consumption. Package submissions, where
even the src.rpm has been given a -devel Name:

* 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.

[Michael Schwendt]

And since I just added a small check for library-less -devel packages
to the -static checker script:

* oprofile : it builds a library-less oprofile-devel sub-package for just
  a single header file (5122 bytes), i.e. it splits off this single file

That's the arbitrariness I refer to. Installation footprint here certainly
is not the reason for this packaging style.

Good however is that is adds a virtual oprofile-static package definition
in the oprofile-devel package. ;-)