Miro Hrončok wrote:
> - cmake files usually go into %{_libdir} and such packages cannot be
> noarch as well
smart cmake noarch projects can use %{_datadir}/cmake instead
-- rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
I wrote:
> Indeed, CMake will also find CMake data under %{_datadir}, and data for
> noarch packages must be installed there.
>
> CMake will not do it automagically for you, you need to actually
> explicitly install the files to the proper place. INSTALL(EXPORTS takes a
> DESTINATION argument:
>
Neal Gompa wrote:
> 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.
Indeed, CMake will also find CMake data under %{_datadir}, and data for
noarch packages must be
Richard Shaw wrote:
> Could you build the package twice using mock (x86_64 and i686) and run
> rpmdiff on them to see if there's anything significant?
FYI, if you use an arch-specific dummy main package and a noarch -devel
subpackage, that is actually automatically done by Koji at every build.
On Tue, Oct 1, 2019 at 11:54 AM Zbigniew Jędrzejewski-Szmek
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 wrote:
> > >>You should not do that, see the "Do not use noarch" part
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 wrote:
> >>You should not do that, see the "Do not use noarch" part of:
> >>
>
On Tue, Oct 1, 2019 at 10:39 AM Miro Hrončok wrote:
>
> - cmake files usually go into %{_libdir} and such packages cannot be
> noarch as well
>
Could you build the package twice using mock (x86_64 and i686) and run
rpmdiff on them to see if there's anything significant?
Thanks,
Richard
On 01. 10. 19 17:22, Jerry James wrote:
On Tue, Oct 1, 2019 at 8:41 AM Miro Hrončok 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
On 01. 10. 19 17:18, Laurent Rineau wrote:
... But I have another concerned, compare to header-only C++ libraries (like
eigen3-devel): what will be the upgrade path? If I remove the main package
`CGAL` (and keep only `CGAL-devel`), nothing will provide an upgrade path from
CGAL-4.14.1-1.
I
On Tue, Oct 1, 2019 at 8:41 AM Miro Hrončok 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.
On Tuesday, October 1, 2019 4:41:29 PM CEST Miro Hrončok wrote:
> On 01. 10. 19 16:24, laurent.rineau__fed...@normalesup.org wrote:
>
> > Another possibility would be to switch to a noarch package, but in the
> > future I would like to package the CGAL examples and demos as
> > sub-packages.
>
>
On 01. 10. 19 16:24, laurent.rineau__fed...@normalesup.org wrote:
Another possibility would be to switch to a noarch package, but in the future I
would like to package the CGAL examples and demos as sub-packages.
You should not do that, see the "Do not use noarch" part of:
The CGAL project (https://www.cgal.org/) has published CGAL-5.0-beta1, that is
now a header-only library (and thus noarch), with arch-dependent dependencies
(boost, gmp, mpfr).
What is the recommended way to update the spec file ?
For the moment, I have let the CGAL package be arch-dependent,
13 matches
Mail list logo
