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

Eli Barzilay wrote:
> 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.
I'd prefer the generated list, as I'm not really a scheme guru :P

BTW, some kind of explicit segregation would even be better than a list 
changing at each release. The very name of the 'src' subdirectory, for 
instance, suggest it contains devel-only files. However, I'm confused by 
the fact it contains images, source and header files:
/usr/lib/plt/collects/plot/src/fit/fit.c
/usr/lib/plt/collects/plot/src/fit/fit.h
/usr/lib/plt/collects/plot/src/fit/fit.o

>>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.
I'm OK for an exception once devel and non-devel files can be safely 
distinguished.

>>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...)
Actually, the error message is confusing:
[guillaume at pomerol guillaume]$ ldd 
/usr/lib/plt/collects/plot/compiled/native/i386-linux/fit-low-level.so
         statically linked

Those .so file are statically linked, whereas they should not.

>>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.)
The last error message (library-not-linked-against-libc) could be a 
rpmlint problem, please ignore for the moment.
[guillaume at pomerol guillaume]$ ldd

>>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.
OK

>>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...
Arg...

I'm joining full report in attached file.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: report
URL: <http://lists.racket-lang.org/users/archive/attachments/20040806/4c14c1d7/attachment.ksh>