Spec URL: http://www.openproofs.org/packages/apron/apron.spec SRPM URL: http://www.openproofs.org/packages/apron/apron-0.9.10_pr-1.fc10.src.rpm Description: APRON is a library of functions that allows the definition and analysis of abstract numerical domains. APRON allows for different types of numerical coefficients, both arbitrary precision floating-point and rational, and different types of domain structures like intervals and polyhedra. It allows for variable assignments and constraints involving domains, and operations on these variables like comparisons, existential quantification, substitution, meet and join. I have done the following with respect to checking the packaging guidelines: rpmlint produces: apron.i386: W: devel-file-in-non-devel-package /usr/lib/libap_pkgrid.a (... many more like this about static libs...) ocaml-apron.i386: W: no-documentation ocaml-apron.i386: W: unstripped-binary-or-object /usr/bin/aprontop ocaml-apron.i386: W: ocaml-mixed-executable /usr/bin/aprontop ocaml-apron.i386: W: unstripped-binary-or-object /usr/bin/ppltop ocaml-apron.i386: W: ocaml-mixed-executable /usr/bin/ppltop ocaml-apron.i386: W: unstripped-binary-or-object /usr/bin/apronppltop ocaml-apron.i386: W: ocaml-mixed-executable /usr/bin/apronppltop 4 packages and 1 specfiles checked; 0 errors, 49 warnings. The first category of warnings are all about inclusion of libraries in the main package. Ostensibly, the whole purpose of the apron package is these libraries, so I was not sure of whether these belong in -devel. Furthermore, these libraries are all static. Ideally, this would not be the case, and I have mentioned to upstream aspects of their build procedure that complicate packaging, and intend to continue to move them toward better practices for packaging compatibility (eg: shared libraries, using standard "configure, make, make install" process). Packaging already requires an extensive set of changes to their makefiles to allow for configuration at locations as specified by RPM parameters (which was included in the form of a patch). If there are more things I should be doing in the short term for the static libraries (eg: moving them all into -devel, creating a -static or a virtual package -static via "provides") or if this static library creation is a problem for packaging this overall, let me know. The second set of warnings are a standard set of warnings for OCaml bytecode binaries - I will tell upstream to try not to "-custom" for future releases (which goes hand-in-hand with switching to shared libraries). Note that the version name is due to the fact that this is a "pre-release" of version 0.9.10 in the sense that 0.9.10 will soon be released and this was taken from the SVN repository as "most of the way there". (It incorporates the changes that are necessary for me to next package Frama-C.) I also verified that the package builds in koji for dist-(f9 to f12) (eg: http://koji.fedoraproject.org/koji/taskinfo?taskID=1331353).
Just a few comments: No parallel make? Sure would go faster on my lots-of-cores builder. If it doesn't work you should at least add a comment indicating that. I'm having trouble understanding the reasoning here: > The first category of warnings are all about inclusion of libraries in the > main package. Ostensibly, the whole purpose of the apron package is these > libraries, so I was not sure of whether these belong in -devel. So here's my question: What good are the static libraries without the headers in the -devel package? Static libraries have no runtime use at all; they'll be embedded into executables at build time The guidelines on static libraries should be pretty clear: http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries They should be in a separate -static package unless you really have no shared libraries at all, in which case they can be in -devel but you must still provide the -static symbol so that other packages can BuildRequires: apron-static. The prelink file confuses me. Why is it in the main package? Actually, why is anything at all in the main package?
Thanks for the comments. (In reply to comment #1) > Just a few comments: > > No parallel make? Sure would go faster on my lots-of-cores builder. If it > doesn't work you should at least add a comment indicating that. I didn't look at this, so I'll see what I can do about allowing this. > I'm having trouble understanding the reasoning here: > > The first category of warnings are all about inclusion of libraries in the > > main package. Ostensibly, the whole purpose of the apron package is these > > libraries, so I was not sure of whether these belong in -devel. > > So here's my question: What good are the static libraries without the headers > in the -devel package? Static libraries have no runtime use at all; they'll be > embedded into executables at build time > > The guidelines on static libraries should be pretty clear: > http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries > They should be in a separate -static package unless you really have no shared > libraries at all, in which case they can be in -devel but you must still > provide the -static symbol so that other packages can BuildRequires: > apron-static. > The prelink file confuses me. Why is it in the main package? You're right - this should go in ocaml-apron. > Actually, why is anything at all in the main package? Well, I would think the few minor documentation files (since they are probably not enough to comprise a whole doc subpackage) could go there. I can certainly move all the static libraries to the devel subpackage, it just seemed odd to put these in apron-devel as the purpose of the whole package is already for development. I saw the guidelines, I just thought another opinion might be in order nonetheless. I'll just move the files to devel as long as it's okay to have essentially an empty main package.
Had you had the headers in the main package as well, I suppose I'd agree with you, but you put them in -devel which makes the main pacakge essentially useless. You didn't answer my question about what good the static libs are without the headers. I don't think there's any actual requirement for you to build a main package at all. Just build -devel, and if upstream in the future starts producing shared libraries then you can start producing a main package containing the libraries, a -devel package with the usual bits and a -static package with the .a files.
Was there any progress? It's been four months since the last comment with no response; I'll go ahead and close this out soon if nothing further happens.
No response; closing.