On Tue, Oct 01, 2019 at 05:38:49PM +0200, Miro Hrončok wrote: > On 01. 10. 19 17:22, Jerry James wrote: > >On Tue, Oct 1, 2019 at 8:41 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > >>You should not do that, see the "Do not use noarch" part of: > >> > >>https://docs.fedoraproject.org/en-US/packaging-guidelines/#_packaging_header_only_libraries > > > >I've been meaning to bring that up. The rationale for not using > >noarch has two parts. > > > >Part 1: "A library should have tests which should be run on all > >architectures." The tests can be built and run in %check without > >including them in the binary RPM. In that case, the fact that the > >library has tests, and that the tests are actually used, has no > >bearing on the noarch/arch-specific status of the binary package. > > > >Part 2: "The install process may modify the installed headers > >depending on the build architecture." If that is true, then the > >package must be arch-specific, as the installed files are not the same > >on all architectures. If that is false, then the package can be > >noarch, as the installed files are the same on all architectures. > > > >For those reasons, I think the "Do not use noarch" section ought to be > >replaced with something like the following: > > > >Be cautious about noarch > > > >Some header-only libraries can be noarch, but be cautious: some > >cannot. Many header-only libraries include tests, demos, or examples > >which are built for all architectures. If any of the built artifacts > >are included in the binary RPM, then it cannot be noarch. Also, the > >install process may modify the installed headers depending on the > >build architecture. If that is done, the package cannot be noarch. > >If a packager wishes to make a header-only library package be noarch, > >the packager must carefully check that the installed files are exactly > >the same on all architectures. Note that this check must be repeated > >when new versions of the library are released. I think this is a change in a good direction. Hopefully, the number of packages which modify headers based on the installation architecture is small. This is generally a very bad idea and a pointless complication for everyone involved. And guidelines should describe the common and simple case first. It is OK to mention that there are some complicated cases which require different approach, but we shouldn't encourage this approach as the default. > 2 cents: > > - if tests are run, the main package should not be naorch, but the > devel subpackage might be ... and this is a much nicer solution. (Specifically: do not set BuildArch on the main package and do not define %files for it, but have a '%package devel' with BuildArch:noarch). koji will build on all architectures and _verify_ that the noarch package is the same everywhere. > - cmake files usually go into %{_libdir} and such packages cannot be noarch as well Oh, cmake. There'll always be causes to build archful packages. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
