[Bug 227669] Review Request: <ppl-0.9> - <A modern C++ library providing numerical abstractions>

[bugzilla at redhat.com]

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 at cs.unipr.it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bagnara at cs.unipr.it




------- Additional Comments From bagnara at cs.unipr.it  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.