rpm cpio error: prelink and SBCL

[Jerry James]

On Thu, Dec 17, 2009 at 1:54 PM, Jakub Jelinek <jakub at redhat.com> wrote:
> You need to first prelink -u on a copy of the program, then
> run it and let it dump itself, then package it up.

Ah, thanks.

> I'd actually argue that such packaging is broken anyway, because you didn't
> compile the binary you are packaging from source, you copied it from
> /usr/bin.

True, so future sbcl updates wouldn't be reflected in the saved image.
 How should I deal with that?  I can think of a few approaches.

1. Put an explicit versioned dependency on the sbcl used to build.
Then every sbcl update breaks upgrades for anyone with my package
installed until I get around to rebuilding it.  It looks like maxima
has taken this approach.

2. Don't dump an executable, but instead store individual FASL files
that are loaded at runtime by whatever version of sbcl happens to be
installed.  The application I'm working with did not take this
approach because of the large size of the application, which would
lead to a significant startup delay.  Plus, the SBCL documentation
explicitly doesn't guarantee that FASL files generated by one version
can be loaded and used without error by another version.

3. Compile sbcl AND the application I really want to build from
source.  Not only will that make my spec file significantly more
complex, but then I have to stay on top of future sbcl updates so I
can update my package, too.  That doesn't seem any better than what
I'm doing now (embedding the existing sbcl binary into my
application).

Even with its faults, #1 seems best to me.  Does anybody see another
approach that will work better?
-- 
Jerry James
http://www.jamezone.org/