On Wednesday, 28 June 2006, at 04:09:56 (-0600),
Bob Proulx wrote:
> > No, don't do this. Packages which (misguidedly) go in /usr/local
> > should not redefine %{_prefix}. In fact, no package should
> > redefine %{_prefix}.
>
> I use /opt/local for truly local packages. In which case I *do*
> want to redefine _prefix. If I were to package something in
> /usr/local (agreed, a bad idea) then I would certainly force it with
> that redefinition. If I want to force /opt/local for my prefix then
> I also need to make that work. Remember, if I want to avoid using
> /usr then I don't want to use the rpm macros file definition and
> must supply my own. Otherwise I can't use the %configure and
> %makeinstall macros and that would be worse.
While I won't spend much time observing that /opt/local is completely
non-standard and against the proper and intended use of /opt, I would
like to note that I said no *package* should redefine %{_prefix}. I
never said the user shouldn't. Packages should rely on the values of
the standard macros, like %{_prefix}, so that users may alter these
values to their hearts' content without the package interfering.
If you set %{_prefix} to /opt/local in your rpmmacros file or
whatever, more power to you. But imagine your frustration with a
package that forceably set it back to /usr or /usr/local.
> Using rpath is Evil. Strong opinions exist there and some
> (misguided) people actually think rpash is a good thing. But it
> truly makes your binary completely unrelocatable.
That's nonsense. "rpath" is simply an additional library search path
which is encoded into the library itself. Nothing is required to be
in an rpath directory; in fact, it needn't even exist. Like most any
other feature, it's not the feature that's bad, but rather the abuses
of the feature.
> In fact you can only really test it
> by installing it! Better to avoid it and simply install your
> libraries a) either in standard places b) into places configured by
> ld.so.conf or c) found with LD_LIBRARY_PATH.
The only difference between rpath and LD_LIBRARY_PATH is that the
former is in the library while the latter is in the environment. They
do the same thing.
> Some enlightened distros even have policies forbidding rpash.
> (Okay, I will wait for the flames to roll in on this one. But I
> will probably ignore them.)
I'm not going to flame you, but I'm not going to agree with you
either. :)
The entity that causes library relocation problems is not rpath, but
rather libtool .la files. These files hard-code the locations of
other .la files for other libraries such that, if the .so.* library is
installed but the .la file isn't, linking fails. *That* is the real
problem, not rpath.
Michael
--
Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <mej@xxxxxxxxx>
n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
"I know that I ought to find someone new, but all I find is myself
always thinking of you. As long as the stars shine bright from the
heavens, long as the rivers run to the sea, I'll never get over you
getting over me." -- Expose
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
