PR#1182: Update information on including header files - packaging-committee

packaging-committee

#1182 Update information on including header files

Closed a year ago by fed500. Opened 2 years ago by fed500.

fed500/packaging-committee headers into master

Update information on including header files in -devel

Benson Muite • 2 years ago

05d3a6d

Header packaging

Benson Muite • 2 years ago

145d2c0

guidelines/modules/ROOT/pages/C_and_C++.adoc

file modified

		`@@ -75,6 +75,12 @@`
		`and instead compatibility functions can be written`
		`to provide backwards compatibility for older applications.`

		`+ If a library requires use of header files, a separate -devel subpackage`
ferdnyc commented 2 years ago What makes this not redundant with line ~1372 of the main guidelines doc?
		`+ should be created and those header files included in that package.`
		`+`
		`== Applications`

		`+ Header files used only internally in an application need not be`
ferdnyc commented 2 years ago Assuming this really needs to be stated anywhere, it definitely does not belong under the "Applications" section of this document.
		`+ packaged.`
		`+`
		`No additional suggestions are provided for applications at this time.`

guidelines/modules/ROOT/pages/index.adoc

file modified

		`@@ -1431,6 +1431,10 @@`
		`or if it is only necessary for development.`
		`If it is only necessary for development, it must go into a -devel package.`

		`+ Header files which are only used internally when compiling an executable`
ferdnyc commented 2 years ago I'm not crazy about putting it on the packager to determine whether headers are internal or public. Generally, packagers should package whatever headers a package installs, since those will be the public headers for any library that's also installed. Every program written in C/C++ will have header files in the source code, but if it's just an executable, those won't be installed, and so they won't be packaged. If we have to say something about this, that seems like the cleaner, clearer split to me, than forcing the responsibility on packagers to figure out what headers are or aren't internal.
		`+ or library, but not used externally with a provided API or library need not`
		`+ be packaged.`
		`+`
		`As with all Fedora Packaging Guidelines,`
		`it is recognized that there are unique situations`
		`that fall outside of the boundaries of this model.`

fed500 commented 2 years ago

Clarify what types of header files are necessary to include in -devel packages.

tibbs commented 2 years ago

I admit I'm having trouble understanding why this needs to be stated. Is someone, somewhere arguing that header files need to be packaged even though they are merely part of the source code of some application or library?

ferdnyc commented on line 10 of guidelines/modules/ROOT/pages/C_and_C++.adoc 2 years ago

Assuming this really needs to be stated anywhere, it definitely does not belong under the "Applications" section of this document.

ferdnyc commented on line 5 of guidelines/modules/ROOT/pages/C_and_C++.adoc 2 years ago

What makes this not redundant with line ~1372 of the main guidelines doc?

ferdnyc commented on line 5 of guidelines/modules/ROOT/pages/index.adoc 2 years ago

I'm not crazy about putting it on the packager to determine whether headers are internal or public. Generally, packagers should package whatever headers a package installs, since those will be the public headers for any library that's also installed. Every program written in C/C++ will have header files in the source code, but if it's just an executable, those won't be installed, and so they won't be packaged.

If we have to say something about this, that seems like the cleaner, clearer split to me, than forcing the responsibility on packagers to figure out what headers are or aren't internal.

Pull-Request has been closed by fed500

a year ago