Arjan van de Ven wrote:
because the simple case breaks.
Now the goal then should maybe be "make packaging self contained apps as
easy as sticking -static on cflags"....
This is the real issue IMHO. I've been ranting about it for a while, and
dug around in the lsb documentation looking for answers, and their
answer is to static link!
I don't know whose problem it really is, but it seems like it would be
some very well spent time to add the ability to rpmbuild to make an
lsb-xx compatible package by compiling against the relevant lsb stubs
and then including all .so's needed to make the application run under
that environment. Unfortunately I'm not adept enough with the guts of
rpm's dependancy tracking to have any idea of how reasonable this
solution is. At the minimum, it would require including -lsb-xx-devel
versions of any runtime libraries that were going to be used, but if the
system were able to compile libraries the same way as applications, it
shouldn't be hard to generate those at all.
Beyond scientific computing, application developers (both open source
and commercial) need better ways to distribute their code in a runnable
(aka binary) form. Just trying to find an mp3 player that would work on
centos4 ended up taking me the better part of 4 hours since there is no
livna for rhel4, and nobody packages for it. If developers had an easy
way to provide me with an lsb-compatible rpm I could have tried a whole
raft of packages and picked one I liked, instead of being stuck with the
first one that would compile and run correctly.
Just my $0.02