STLPort 4.6.2 for possible inclusion in Fedora Extras.

[Michael Schwendt]

On Sun, 08 May 2005 23:08:59 +1000, Ben Martin wrote:

> Hi,
>   After chatting with some Fedora folks at linux.conf.au I have decided
> to start the process of packaging libferris available [1] via extras.
> I'm he author of the libferris project and many of its spin off
> sublibraries. To start the process I have decided to put forward STLport
> for inclusion. 
> 
> In keeping with [2] I have updated my existing specfile and rolled a
> src.rpm which are both available:
> http://kvo.itee.uq.edu.au/~martin/STLport.spec
> http://kvo.itee.uq.edu.au/~martin/STLport-4.6.2-1.src.rpm
> 
> The specfile creates a pkg-config .pc file and as such requires knowing
> where prefix and libdir are going to be.

They come predefined as %_prefix, %_exec_prefix, %_libdir, and
%_includedir. Don't redefine them. In particular, %_libdir expands
to /usr/lib64 on 64-bit multilib platforms, so "%define libdir
/usr/lib" would break badly when you use it.

> I don't really mind removing
> the .pc file and if that is done the specfile should be more "normal".
> The main reason I include the .pc file generation is that it
> makes ./configure on clients much faster if you don't have to poke
> around the system and try_link() all the time to find your stlport. Of
> course the ./configures I have that *use* the stlport package all drop
> back to probing and try_link() but they first attempt to find by pkg-
> config.
> 
> rpmlint complains about the protections of the source + patches being
> incorrect, 

Unimportant with CVS. No files are executable => good.

> a lack no-soname for the library and  wrong-script-end-of-
> line-encoding for some headers. I suspect the header thing is either
> rpmlint being overparanoid or I have forgotten a directive in the
> specfile. 
>
> The soname thing I am unsure of how to fix.

With additional linker options in the Makefile, where the shared object
library is created. But that ought to be done in agreement with upstream
developers. (libstlport_gcc.so.4)

> The hardcoded-library-path error is to do with the fact that I need to
> know where the library is to make a .pc file for it. 

See above.
 
> The License in the spec is not quite right, see its README for details.

Yes, GPL is not right and hence must not be put into the spec file and
package. The licence is a bit like BSD/MIT, but even less complex.


Regardless of whether C++ developers may be aware of what STL means, I
would mention the term "Standard Template Library" somewhere in the
%descripton or even in the summary.

> E: STLport no-signature
> 
> $ rpmlint /tmp/rpmbuild/RPM/RPMS/athlon/STLport-devel-4.6.2-1.athlon.rpm
> W: STLport-devel no-major-in-name STLport-devel

Can be ignored. rpmlint prefers different naming guidelines.

> W: STLport-devel no-documentation

Indeed. ./doc directory of the source contains fine HTML docs,
including a licence.html where they call it "Free License".

> E: STLport-devel wrong-script-end-of-line-
> encoding /usr/include/stlport/stl/debug/_relops_hash_cont.h
> E: STLport-devel wrong-script-end-of-line-
> encoding /usr/include/stlport/stl/debug/_relops_cont.h
> E: STLport-devel wrong-script-end-of-line-
> encoding /usr/include/stlport/config/_msvc_warnings_off.h

This means that there are Windows-like line delimiters in the file,
i.e. carriage-return + line-feed instead of just line-feed. This can
confuse preprocessors, compilers. Hence the rpmlint complaint. It's
better to convert such files with sed (or dos2unix).

> E: STLport-devel zero-length /usr/include/stlport/stl/_exception.h
> E: STLport-devel no-signature

Private header file, not included anywhere.


During build, all the compiler warnings about mutexes are a bit scary.

> %package devel
> Summary: STLPort headers, static libraries and documentation
> Group: System Environment/Libraries
> Requires: %{name} = %{version}

Please make it "Requires: %{name} = %{version}-%{release}" for all
sub-packages, so the main package is always the right one for any
sub-package (important for changes in API/features).


Beginning of %install section must empty buildroot directory (exactly
like the %clean section does it).


> %files debuglib
> %defattr(-,root,root,0755)
> %{libdir}/libstlport_gcc_stldebug.*

Build fails because there is a broken symlink, which is not
included in the package:
libstlport_gcc_debug.so -> libstlport_gcc_debug.so.4.6

error: Installed (but unpackaged) file(s) found:
   /usr/lib/libstlport_gcc_debug.so


So much for a first brief look...

-- 
Michael Schwendt <mschwendt at users.sf.net>
Fedora Core release 4 (Stentz) - Linux 2.6.11-1.1369_FC4