[plt-scheme] miscaellanous packaging problems with plt-scheme

On Aug  5, Guillaume Rousse wrote:
> First, i got tons of warning about development files (*.h and *.c) 
> inside package:
> devel-file-in-non-devel-package /usr/lib/plt/collects/plot/src/all/plcont.c
> devel-file-in-non-devel-package 
> /usr/lib/plt/collects/plot/src/all/gd_io_dp.c
> devel-file-in-non-devel-package /usr/lib/plt/collects/plot/src/all/plot3d.c
> devel-file-in-non-devel-package /usr/lib/plt/collects/compiler/mzc.h
> etc...

As Jamie said, there is a rather sophisticated script that filters out
the necessary files based on the platform, the package etc.  (For
example, the specification for plot:

  plot := (- (tag only-docindex (package: "plot"))
             (cond (not src) => "src/"))

says that the its "src" directory is not included in non-source packages,
and that only its the documentation index is included in the
distribution.)

I can send you the specs and the script so you can see if that helps,
or I can send you the generated file lists (which you could get by
downloading the distributions and looking what's included).  BTW, if
such lists of file contents are useful for people who compile external
packages, then I can make these things available on the download
server.


> The policy says that files not mandatory for execution, but only for
> compiling new derived applications, such as static libs and headers
> have to be segregated in a -devel packages. And source files are
> only needed as doc. But some specific packages, such as compilers
> for instance, need those file for standard use. So my question is:
> should I request an exception for plt also, or create a plt-devel
> package containing them ?

In the above case, the plot/src is not needed for a normal
distribution but things like collects/compiler/mzc.h or the include
directory are certainly needed.  The above script does exactly this
kind of discrimination (so if plot/src was not omitted, it should have
been considered a packaging bug).

In generally, I think that an exception is definitely needed.  This is
a language implementation, intended for programmers, so it comes with
a lot of stuff that are naturally the devel-type.


> Then I have different errors, mostly about the dynamic libraries:
> 
> 1)
> shared-lib-without-dependency-information 
> /usr/lib/plt/collects/plot/compiled/native/i386-linux/fit-low-level.so
> shared-lib-without-dependency-information 
> /usr/lib/plt/collects/plot/compiled/native/i386-linux/plplot-low-level.so
> etc...

(Don't know what this dependency information should be...)


> 2)
> E: plt-mzscheme binary-or-shlib-defines-rpath /usr/lib/plt/bin/mzscheme 
> ['/usr/lib']
> The binary or shared library defines the `RPATH'. Usually this is a
> bad thing because it hard codes the path to search libraries and so it
> makes difficult to move libraries around.  Most likely you will find a
> Makefile with a line like: gcc test.o -o test -Wl,--rpath.
> 
> 3)
> E: plt-mzscheme library-not-linked-against-libc 
> /usr/lib/plt/collects/openssl/compiled/native/i386-linux/mzssl.so

Matthew?

(The rpath is probably coming from plt/src/wxcommon/jpeg.)


> 4)
> zero-length /usr/lib/plt/collects/launcher/sh

?


> zero-length /usr/lib/plt/collects/doc/drscheme/keywords.scm

I think that these files should not be included.


> I'm unable to explain 1), 2) is explained by rpmlint itself, and 3) and 
> 4) are quite self-explanatory
> 
> Full report is available online (with many other packages tough):
> http://qa.mandrakesoft.com/stat.cgi?error=all&maintainer=guillomovitch@mandrake.org&sort1=0&sort2=6&warning=all&type=RPMS&type=SRPMS&class=main&class=contrib&view=detailed

Inaccessible without an account...

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!