OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)
Toshio Kuratomi wrote:
On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote:
Nigel Jones wrote:
Hi everyone,
While putting in a couple of packages for Extras Review I've stumbled into a couple of issues regarding how Ocaml links libraries and how the Fedora Packaging Guidelines are set.
My packages in question are: ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804) camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805) freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815)
Basically, ocamlSDL and camlimages produce two sets of libraries (a set of dynamic libraries, and another set for development etc), sadly when other packages like freetennis build, they staticly link to libraries such as camlimages/ocamlSDL.
I found it semi-suspect when I built freetennis, and hence why I asked on bugzilla when I posted the three packages for review, however I did some more questioning today and after a quick IRC discussion in #ocaml was told:
12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries right? 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes. 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading. 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for dynamic loading as static loading.
Looking at my installed files on my laptop, lablgl, lablgtk and labltk (as well as the main ocaml package) store .a, .cma and .cmxa files in /usr/lib/ocaml (and subfolders).
As I'm only new to Fedora packaging, could someone please advise on where I should from here on the matter and what the position of FESCO is on Ocaml static libraries, and where I should go from here.
Thanks,
Nigel Jones
I'm just wondering if anyone has any thoughts on this issue.
I've talked to some more people in #ocaml (Freenode), who suggested that I try a patch by the name of 'scaml' which is a year or two old (and although can be manually applied to the ocaml source, it does not work (problems with assembly which I've not comfortable meddling with).
We'd actually need to downgrade to 3.07 which was removed from Fedora in Feb 05 to get the patch working to satisfy the need for dynamic loading which I'm sure would upset a few people.
Upstream already have a bug opened stating that they need to fix the issue but they have never updated it, or assigned it to anyone.
So my main question is "where to from here?"
I think, if the ocaml compiler doesn't support dynamic libraries, static linking would be acceptable. This doesn't mean that we shouldn't press upstream to add dynamic linking (and convert all our packages when that becomes available) just an acknowledgment that fixing the limitation has to be done upstream (it could be done by someone within Fedora but the fix needs to go upstream).
This is similar to allowing C libraries in even if they only build statically.
If I'm not understanding precisely what the limitation is, feel free to clarify.
There are two issues here: (a) Having OCaml binaries link dynamically instead of statically to OCaml libraries. (b) Writing a dynamic library in OCaml, and having it used by programs written in other languages, particularly C.
I suspect it's unlikely that upstream will do (a), ever. There's a technical issue. OCaml really doesn't have a concept of an ABI. It does a kind of whole-program optimisation where even changes to the internal implementation of a library can affect the resulting binary. Moreover even if you "fixed" that, any change whatsoever to the library's signature or the version of compiler it was built with (even bugfix releases which have the same version number) will make the library incompatible.
You might also find this entertaining:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c...
Another issue which Xavier doesn't mention is the ability to fix a security bug in a shared library, and not require all dependent applications be recompiled. Well, there aren't many (any?) widely used OCaml libraries, and there aren't a lot of binaries which would need to be recompiled either. But it could be a problem for OCaml world domination plans.
As for (b), the ability to write libraries in a sane language and have them called through a C API: This almost works. Well, it works well on i386, but there are some problems on x86-64. I'm looking forward to having this. It needs some tools to make it work well - it would be nice to have the C header files and the complex Makefile fragments to get it to work generated automatically.
Rich.
On Sat, 2007-05-19 at 17:36 +0100, Richard W.M. Jones wrote:
Toshio Kuratomi wrote:
I think, if the ocaml compiler doesn't support dynamic libraries, static linking would be acceptable. This doesn't mean that we shouldn't press upstream to add dynamic linking (and convert all our packages when that becomes available) just an acknowledgment that fixing the limitation has to be done upstream (it could be done by someone within Fedora but the fix needs to go upstream).
This is similar to allowing C libraries in even if they only build statically.
If I'm not understanding precisely what the limitation is, feel free to clarify.
There are two issues here: (a) Having OCaml binaries link dynamically instead of statically to OCaml libraries. (b) Writing a dynamic library in OCaml, and having it used by programs written in other languages, particularly C.
I suspect it's unlikely that upstream will do (a), ever. There's a technical issue. OCaml really doesn't have a concept of an ABI. It does a kind of whole-program optimisation where even changes to the internal implementation of a library can affect the resulting binary. Moreover even if you "fixed" that, any change whatsoever to the library's signature or the version of compiler it was built with (even bugfix releases which have the same version number) will make the library incompatible.
You might also find this entertaining:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c...
Another issue which Xavier doesn't mention is the ability to fix a security bug in a shared library, and not require all dependent applications be recompiled. Well, there aren't many (any?) widely used OCaml libraries, and there aren't a lot of binaries which would need to be recompiled either. But it could be a problem for OCaml world domination plans.
As for (b), the ability to write libraries in a sane language and have them called through a C API: This almost works. Well, it works well on i386, but there are some problems on x86-64. I'm looking forward to having this. It needs some tools to make it work well - it would be nice to have the C header files and the complex Makefile fragments to get it to work generated automatically.
Could you add something to http://fedoraproject.org/wiki/PackagingDrafts/OCaml about this? I'd imagine we'd need to say something like "OCaml packages must have a strict Requires: on the version and release of ocaml" with some examples. And something should be said about rebuilding OCaml packages when libraries they depend on are updated as well so that security problems and bugfixes are incorporated into the new package.
Thanks, -Toshio
Toshio Kuratomi wrote:
Could you add something to http://fedoraproject.org/wiki/PackagingDrafts/OCaml about this? I'd imagine we'd need to say something like "OCaml packages must have a strict Requires: on the version and release of ocaml" with some examples. And something should be said about rebuilding OCaml packages when libraries they depend on are updated as well so that security problems and bugfixes are incorporated into the new package.
Yes ... Revising that page is next on my list of things to do - it's totally wrong.
However before I do that I would like to have someone look over my spec files - see: http://tinyurl.com/2rl4w6 (goes to a long bugzilla URL).
Rich.
Toshio Kuratomi wrote:
Could you add something to http://fedoraproject.org/wiki/PackagingDrafts/OCaml about this?
I've updated that page, and built 8 libraries in that style.
Rich.
On Sat, 2007-05-26 at 15:16 +0100, Richard W.M. Jones wrote:
Toshio Kuratomi wrote:
Could you add something to http://fedoraproject.org/wiki/PackagingDrafts/OCaml about this?
I've updated that page, and built 8 libraries in that style.
Thanks! To my un-OCaml eyes, that looks pretty good. I have one question: ''' There are two scripts in the base ocaml package which automatically calculate the right Requires and Provides for a library. To use them, just add the following to the spec file:
%define _use_internal_dependency_generator 0 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh '''
The version of ocaml-find-* scripts that were posted to the list only appeared to find ocaml requires and provides. But OCaml can link to C code as well. Do we want to turn off the internal_dependency_generator or do we want to supplement it?
-Toshio
Toshio Kuratomi wrote:
On Sat, 2007-05-26 at 15:16 +0100, Richard W.M. Jones wrote:
Toshio Kuratomi wrote:
Could you add something to http://fedoraproject.org/wiki/PackagingDrafts/OCaml about this?
I've updated that page, and built 8 libraries in that style.
Thanks! To my un-OCaml eyes, that looks pretty good. I have one question: ''' There are two scripts in the base ocaml package which automatically calculate the right Requires and Provides for a library. To use them, just add the following to the spec file:
%define _use_internal_dependency_generator 0 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh '''
The version of ocaml-find-* scripts that were posted to the list only appeared to find ocaml requires and provides. But OCaml can link to C code as well. Do we want to turn off the internal_dependency_generator or do we want to supplement it?
I've attached the latest versions to this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004
These versions call the ordinary find-requires and find-provides first, before going on to look at OCaml-specific files. And they appear to find C dependencies (.so files and the like). For example, here is my ocaml-pcre package[1], which is a library which links to the C PCRE lib:
$ rpm -q --requires ocaml-pcre rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libpcre.so.0()(64bit) ocaml-Array-a904b798dd9665c2d3635636d293403c ocaml-Callback-0ee2712bb82e3d81660a3132766fcb9b ocaml-Char-0d0f20d5854680b694159a2fb0ca4e61 ocaml-List-5a0e3217fc356bd18f60bff31861dfd3 ocaml-Pervasives-71f888453b0f26895819460a72f07493 ocaml-String-fec8292bb1a02d2c7b8b4ba7b83a7d8b ocaml-Sys-8cce770a42b7d0e4d85569c15d7841d6 ocaml = 3.09.3-2.fc6
$ rpm -q --provides ocaml-pcre dllpcre_stubs.so()(64bit) ocaml-Pcre-0ad0922a407866904c71fd615f05b414 ocaml-pcre = 5.11.4-3
So that's correct, I think?
Rich.
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240652
BTW, in case it wasn't clear with all this talk about static linking. OCaml links OCaml libraries statically, but C libraries dynamically. For example here is cduce, an OCaml program which uses many different libraries:
$ ldd `which cduce` libexpat.so.0 => /lib64/libexpat.so.0 (0x0000003c76e00000) libcurl.so.3 => /usr/lib64/libcurl.so.3 (0x0000003fb7000000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000003fbaa00000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003fbb200000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003fbae00000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003c79600000) libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003c78600000) libdl.so.2 => /lib64/libdl.so.2 (0x0000003c73600000) libidn.so.11 => /usr/lib64/libidn.so.11 (0x0000003297800000) libssl.so.6 => /lib64/libssl.so.6 (0x0000003fbb600000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0000003c79200000) libz.so.1 => /usr/lib64/libz.so.1 (0x0000003c74200000) librt.so.1 => /lib64/librt.so.1 (0x00000038b2200000) libpcre.so.0 => /lib64/libpcre.so.0 (0x0000003682000000) libm.so.6 => /lib64/libm.so.6 (0x0000003c73a00000) libc.so.6 => /lib64/libc.so.6 (0x0000003c73200000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x0000003fba600000) /lib64/ld-linux-x86-64.so.2 (0x0000003c72e00000) libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003ff2400000) $ file `which cduce` /usr/bin/cduce: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
Rich.
On 5/28/07, Richard W.M. Jones rjones@redhat.com wrote:
Toshio Kuratomi wrote:
Thanks! To my un-OCaml eyes, that looks pretty good. I have one question: ''' There are two scripts in the base ocaml package which automatically calculate the right Requires and Provides for a library. To use them, just add the following to the spec file:
%define _use_internal_dependency_generator 0 %define __find_requires /usr/lib/rpm/ocaml-find-requires.sh %define __find_provides /usr/lib/rpm/ocaml-find-provides.sh '''
The version of ocaml-find-* scripts that were posted to the list only appeared to find ocaml requires and provides. But OCaml can link to C code as well. Do we want to turn off the internal_dependency_generator or do we want to supplement it?
I've attached the latest versions to this bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239004
These versions call the ordinary find-requires and find-provides first, before going on to look at OCaml-specific files. And they appear to find C dependencies (.so files and the like). For example, here is my ocaml-pcre package[1], which is a library which links to the C PCRE lib:
Thanks, those scripts look good.
-Toshio -Toshio
Toshio Kuratomi wrote:
Thanks, those scripts look good.
So what's the next step? I've added (or in two cases, changed) 14 OCaml packages which are waiting for another person to review them. You can get the full list of Bugzillas through this link:
I understand that everyone's really busy getting F7 out of the door, and also that OCaml doesn't interest many people. But anyway to kick things off, here are some of the things which I think could be problems:
(1) Because of the strict dependencies, users could only upgrade ocaml + all OCaml libraries they are using in one go.
(2) Also as a consequence of (1), if a major release of OCaml comes out, all OCaml libraries have to be upgraded at the same time. If, for example, we move to 3.10, then all libraries upstream must support 3.10.
--> Possible solution to (1) & (2): Put the version number in the library path, as Debian does. This may allow multiple versions to coexist.
--> Upstream support (2) is not much of a problem in reality.
(3) OCaml contains a native code compiler, but that compiler hasn't been ported to all architectures that Fedora supports. It has a bytecode compiler which works everywhere (but is interpreted and hence slow). I haven't been very careful about detecting if native code is supported on the current architecture.
--> ExcludeArch and/or lots of nasty %ifarch sections in %files.
--> I don't have a non-native arch to test on.
(4) rpmlint gives a few familiar warnings:
devel-file-in-non-devel-package (about *.cmi files)
--> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241471
only-non-binary-in-usr-lib
--> A consequence of the above.
unstripped-binary-or-object
--> You can't strip OCaml bytecode binaries because the bytecode gets stripped too. Arguably that's an upstream bug.
no-binary
--> Packages which contain no binaries should be in noarch - fair enough, but I don't know how to do this in the spec file and keep the subpackages arch-specific.
configure-without-libdir-spec
--> The ./configure scripts are often written in OCaml and don't use the standard autoconf options.
(5) How does the Fedora build system work? To build a library you need to have the OCaml compiler and all dependent libraries installed (enforced through BuildRequires) and you'll get out an RPM which only installs with the precise compiler and library which were installed when it was compiled. So the only sequence that works is: # remove all ocaml RPMs $ rpmbuild -ba ocaml.spec # install ocaml RPM $ rpmbuild -ba ocaml-lib1.spec # install ocaml lib1 RPM $ rpmbuild -ba ocaml-lib2.spec # install ocaml lib2 RPM etc.
Rich.
On Wed, 2007-05-30 at 15:14 +0100, Richard W.M. Jones wrote:
Toshio Kuratomi wrote:
Thanks, those scripts look good.
So what's the next step? I've added (or in two cases, changed) 14 OCaml packages which are waiting for another person to review them. You can get the full list of Bugzillas through this link:
If you, Gérard, Hans, and the other people working on OCaml think the guidelines are ready we can discuss and vote to include them at next week's packaging meeting. The committee is meeting at Tuesday at 17:00 UTC for about an hour in #fedora-meeting on freenode IRC. If any of you can make it to the meeting that would be great as it helps to have someone familiar with the language there to field any questions that may come up.
I understand that everyone's really busy getting F7 out of the door, and also that OCaml doesn't interest many people. But anyway to kick things off, here are some of the things which I think could be problems:
(1) Because of the strict dependencies, users could only upgrade ocaml + all OCaml libraries they are using in one go.
(2) Also as a consequence of (1), if a major release of OCaml comes out, all OCaml libraries have to be upgraded at the same time. If, for example, we move to 3.10, then all libraries upstream must support 3.10.
--> Possible solution to (1) & (2): Put the version number in the library path, as Debian does. This may allow multiple versions to coexist.
--> Upstream support (2) is not much of a problem in reality.
Other packages like this (python, perl, ruby) do have versioned subdirectories so that might be the best way to go. Do upstream build scripts generally make this easy to do?
(3) OCaml contains a native code compiler, but that compiler hasn't been ported to all architectures that Fedora supports. It has a bytecode compiler which works everywhere (but is interpreted and hence slow). I haven't been very careful about detecting if native code is supported on the current architecture.
--> ExcludeArch and/or lots of nasty %ifarch sections in %files.
--> I don't have a non-native arch to test on.
What's missing? ppc64? Is there a possibility of support being added upstream? I can't think of any other packages/languages that have this problem offhand. We may need to do something nasty with subpackages and %ifarch but I'd rather avoid that if possible. I don't know how possible that is, though.
(4) rpmlint gives a few familiar warnings:
devel-file-in-non-devel-package (about *.cmi files)
--> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241471
Looks like this one is being worked on.
only-non-binary-in-usr-lib
--> A consequence of the above.unstripped-binary-or-object
--> You can't strip OCaml bytecode binaries because the bytecode gets stripped too. Arguably that's an upstream bug.
no-binary
--> Packages which contain no binaries should be in noarch - fair enough, but I don't know how to do this in the spec file and keep the subpackages arch-specific.
Yeah -- if one package/subpackage is arch specific then all of the pieces built from it have to be.
configure-without-libdir-spec
--> The ./configure scripts are often written in OCaml and don't use the standard autoconf options.
Okay. So this looks like rpmlint sees ./configure as an autoconf configure script when it really is not.
(5) How does the Fedora build system work? To build a library you need to have the OCaml compiler and all dependent libraries installed (enforced through BuildRequires) and you'll get out an RPM which only installs with the precise compiler and library which were installed when it was compiled. So the only sequence that works is: # remove all ocaml RPMs $ rpmbuild -ba ocaml.spec # install ocaml RPM $ rpmbuild -ba ocaml-lib1.spec # install ocaml lib1 RPM $ rpmbuild -ba ocaml-lib2.spec # install ocaml lib2 RPM etc.
Every build is a fresh mock buildroot. It includes the packages in the minimal install plus BuildRequires and their dependencies. The packages are drawn from the current download repository plus the packages that have been built recently but not yet made it to the repository. With the new koji builders (for F7) you have to tell it to do a chainbuild to guarantee that the recently built package is included in the new build. Until a better UI is worked out, here's a post on how to do that:
http://www.redhat.com/archives/fedora-devel-list/2007-May/msg01850.html
I think that will take care of getting new versions of OCaml through the build system.
-Toshio
Toshio Kuratomi wrote:
If you, Gérard, Hans, and the other people working on OCaml think the guidelines are ready we can discuss and vote to include them at next week's packaging meeting. The committee is meeting at Tuesday at 17:00 UTC for about an hour in #fedora-meeting on freenode IRC.
It's in my diary.
(3) OCaml contains a native code compiler, but that compiler hasn't been ported to all architectures that Fedora supports. It has a bytecode compiler which works everywhere (but is interpreted and hence slow). I haven't been very careful about detecting if native code is supported on the current architecture.
--> ExcludeArch and/or lots of nasty %ifarch sections in %files.
--> I don't have a non-native arch to test on.
What's missing? ppc64? Is there a possibility of support being added upstream? I can't think of any other packages/languages that have this problem offhand. We may need to do something nasty with subpackages and %ifarch but I'd rather avoid that if possible. I don't know how possible that is, though.
I ended up copying the solution that Debian use -- when building detect if ocamlopt (the native code compiler) is available.
http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=show#head-14a9d22...
I built four packages this way, testing on a "simulated" bytecode-only architecture.
Rich.
Richard W.M. Jones wrote:
I suspect it's unlikely that upstream will do (a), ever. There's a technical issue. OCaml really doesn't have a concept of an ABI. It does a kind of whole-program optimisation where even changes to the internal implementation of a library can affect the resulting binary. Moreover even if you "fixed" that, any change whatsoever to the library's signature or the version of compiler it was built with (even bugfix releases which have the same version number) will make the library incompatible.
You might also find this entertaining:
http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c...
I always like to be proven wrong ... An experimental dynamic linking of native code patch has just been added to OCaml CVS upstream.
Rich.
On Sat, 2007-06-02 at 15:21 +0100, Richard W.M. Jones wrote:
Toshio Kuratomi wrote:
If you, Gérard, Hans, and the other people working on OCaml think the guidelines are ready we can discuss and vote to include them at next week's packaging meeting. The committee is meeting at Tuesday at 17:00 UTC for about an hour in #fedora-meeting on freenode IRC.
It's in my diary.
(3) OCaml contains a native code compiler, but that compiler hasn't been ported to all architectures that Fedora supports. It has a bytecode compiler which works everywhere (but is interpreted and hence slow). I haven't been very careful about detecting if native code is supported on the current architecture.
--> ExcludeArch and/or lots of nasty %ifarch sections in %files.
--> I don't have a non-native arch to test on.
What's missing? ppc64? Is there a possibility of support being added upstream? I can't think of any other packages/languages that have this problem offhand. We may need to do something nasty with subpackages and %ifarch but I'd rather avoid that if possible. I don't know how possible that is, though.
I ended up copying the solution that Debian use -- when building detect if ocamlopt (the native code compiler) is available.
http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=show#head-14a9d22...
I built four packages this way, testing on a "simulated" bytecode-only architecture.
Looks good. What are the caveats to doing things this way for the % files section? I imagine as long as wildcards are used it will work but we might want to have an example with a comment saying that the wildcard makes it work on both native and non-native archs.
-Toshio
Toshio Kuratomi wrote:
On Sat, 2007-06-02 at 15:21 +0100, Richard W.M. Jones wrote:
I ended up copying the solution that Debian use -- when building detect if ocamlopt (the native code compiler) is available.
http://fedoraproject.org/wiki/PackagingDrafts/OCaml?action=show#head-14a9d22...
I built four packages this way, testing on a "simulated" bytecode-only architecture.
Looks good. What are the caveats to doing things this way for the % files section? I imagine as long as wildcards are used it will work but we might want to have an example with a comment saying that the wildcard makes it work on both native and non-native archs.
With the four packages I did so far, I ended up with %if %opt conditionals in the %files section. For example:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240571 http://annexia.org/tmp/ocaml-calendar.spec
has:
%files devel %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/META %if %opt %{_libdir}/ocaml/calendar/*.a %{_libdir}/ocaml/calendar/*.cmxa %endif %{_libdir}/ocaml/calendar/*.mli
Is that not right?
Rich.
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> With the four packages I did so far, I ended up with %if %opt RWMJ> conditionals in the %files section.
That seems distasteful for some reason. Here are all of the %files sections:
%files %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/*.cma %{_libdir}/ocaml/calendar/*.cmi
%files devel %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/META %if %opt %{_libdir}/ocaml/calendar/*.a %{_libdir}/ocaml/calendar/*.cmxa %endif %{_libdir}/ocaml/calendar/*.mli
First, what owns the directory %{_libdir}/ocaml/calendar?
I'm not sure if it's less distasteful have the conditional or just do
%{_libdir}/ocaml/calendar/* %exclude %{_libdir}/ocaml/calendar/*.cm[ai]
or if that even works the way I'm hoping it does.
Jason L Tibbitts III wrote:
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> With the four packages I did so far, I ended up with %if %opt RWMJ> conditionals in the %files section.
That seems distasteful for some reason. Here are all of the %files sections:
%files %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/*.cma %{_libdir}/ocaml/calendar/*.cmi
%files devel %defattr(-,root,root,-) %doc CHANGES README TODO %{_libdir}/ocaml/calendar/META %if %opt %{_libdir}/ocaml/calendar/*.a %{_libdir}/ocaml/calendar/*.cmxa %endif %{_libdir}/ocaml/calendar/*.mli
First, what owns the directory %{_libdir}/ocaml/calendar?
I'm not sure if it's less distasteful have the conditional or just do
%{_libdir}/ocaml/calendar/* %exclude %{_libdir}/ocaml/calendar/*.cm[ai]
or if that even works the way I'm hoping it does.
Does this look better?
http://www.annexia.org/tmp/ocaml/ocaml-calendar.spec
Rich.
"RWMJ" == Richard W M Jones rjones@redhat.com writes:
RWMJ> Does this look better?
I think that's probably as good as we can hope for without disabling failure on a non-matching glob. (I don't even know if that's possible.)
- J<
packaging@lists.fedoraproject.org
-
Jason L Tibbitts III -
Richard W.M. Jones -
Toshio Kuratomi