On Tue, Oct 1, 2019 at 11:54 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > 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. > If it's a header-only library, CMake stuff being installed into %{_libdir} is probably wrong. CMake has a noarch path in %{_datadir}, so it probably needs fixing to use that. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
