Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: <ppl-0.9> - <A modern C++ library providing numerical abstractions> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227669 bagnara@xxxxxxxxxxx changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bagnara@xxxxxxxxxxx ------- Additional Comments From bagnara@xxxxxxxxxxx 2007-02-10 09:40 EST ------- Thank you very much for the detailed report. We have now fixed all the problems indicated by `rpmlint -i' and most of the issues you pointed out. We would need further advice for the following items though. > > Requires: gmp >= 4.1.3, gcc-c++ >= 4.0.2 > > Both are wrong. Instead, you want "BuildRequires: gmp-devel", > provided that you want to compile with GNU MP. If so, the dependency > on the GNU MP library soname is automatically inserted by rpmbuild. Right. I have added "BuildRequires: gmp-devel". But shouldn't we also have "Requires: gmp-devel"? I mean, the PPL header files include the GMP header files, so to use the library (as well as to build it) the GMP header files must be present. Moreover, building the library also requires gcc, gcc-c++ and probably many other tools: should these all be listed? Also, using the library certainly requires libstdc++ and building requires libstdc++-devel. What is the rationale here? > > Prefix: /usr > > This means that you want to mark the packages as relocatable. > Whether it really is relocatable remains to be seen after bringing > it into shape first. You can safely delete this line unless you > insist on making it relocatable. I have temporarily commented it out. As you say, we can see later whether the packages are relocatable. > Don't include static libraries. If possible, disable them at configure > time with --disable-static or just delete them in %install. Is this really necessary? Some applications require static libraries. What if we put the static libraries in the *-devel packages? This is what is done in, e.g., the gmp-devel package. > Also don't include libtool archive files *.la. OK. > > %files c > > Same here. A "ppl-c-devel" package is missing. But doesn't it make > sense to put C and C++ library and API into the "ppl" and > "ppl-devel" packages? The PPL consists of one core library and several interfaces (C++, C plus 6 Prolog dialects; in forthcoming version 0.10 there are also an OCaml and a Java interface). The interfaces are all independent from one another and most user will only need one or perhaps two of them. So it seemed a good idea to have them separate, also because they have quite stringent and different requirements. What is the policy? Should all the packages be split in a pair made up of "package" and "package-devel"? I ask this because, we may end up producing lots of packages: ppl base library code (C++ shared library), license ppl-devel ppl-config, documentation ppl-cxx-devel C++ interface header file and static library ppl-c C interface shared library ppl-c-devel C interface header file and static library ppl-java ... ppl-java-devel ppl-ocaml ppl-ocaml-devel ppl-some-prolog ppl-some-prolog-devel [the last two items multiplied by 6] To these we should probably add ppl-lpsol a program that also depends on glpk-devel I don't know if this is the way to go. A few observations: 1) ppl-cxx is not present in the list above because I don't know what it could contain that is not already in the base ppl package. 2) It is possible to reduce the number of packages by merging the C and the C++ interfaces: the only drawback is that those who only use one of the two interfaces would waste some disk space. 3) To reduce the number of packages further, the distinction between base and devel packages could be dropped for the other interfaces: it is quite likely that those who need ppl-some-prolog will need also ppl-some-prolog-devel. Of course, if the number of packages is not something we should worry about we could go for the cleanest solution and split the library as indicated above. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review