Jeremy White wrote:
> > > I would like to submit a patch to disable rpath
> > > by default, and add a '--enable-rpath[=DIR]' configure
> > > options. Objections?
> > we do have to use rpath so that we don't need to tweak
> > the LD_LIBRARY_PATH or /etc/ld.conf on any user configuration
> >
> > since your request is specific (and using rpath seemed to be
> > agreed on latest Wine bottling discussion), I'd suggest doing
> > it the other way around:
> > - keep rpath as default
> > - add a configure.in option (--disable-rpath) to remove that
> > feature in case it's not wished
> >
>
> You know, I didn't realize how well Alexandre had set me up.
> I had sent a --with[out]-rpath=DIR patch to Alexandre, which behaved
> exactly as you suggested, and asked for his feedback.
>
> He responded:
>
> > So if I get this right, what you do is that you don't set -rpath at
> > all? I'm beginning to think this should actually be the standard
> > behavior; setting rpath is broken because it takes precedence over
> > LD_LIBRARY_PATH. How about submitting a patch that removes rpath
> > completely, and start a nice flame^H^H^H^H^Hdiscussion on wine-devel?
>
> I'm sorry for picking at this scab, but after some thought, I
> think he's right.
>
> If the -rpath did *not* take precedent over LD_LIBRARY_PATH,
> then I would not object to it, but that precedence is, IMHO, a nasty
> hidden surprise.
>
Well, you've got my vote on this one. A packaged wine should really change
the /etc/ld.so.conf and/or use a hack similar to the QT packages (See my
earlier mail on this) rather than use -rpath, especially since it totally
disallows relocating the package. However Ove in particular did not agree
with me stating that elf versioning takes care of this for us. Personally
I feel I would rather have the whole package installed in a completely
different prefix, especially since more than just libraries are involved
(e.g. the server).
>
> For example, in the RPM I've nearly finished building,
> I've allowed for the installation to be relocated.
> So, you can do rpm -i wine-0.2000-1108 (which goes to /opt/wine).
> Later, you can do a rpm -i --prefix=/opt/newwine wine-0.2000-1216,
> and install to /opt/newwine.
>
Perfect, I had recommended allowing wine to be relocated earlier but no one
seemed to really like the idea-- although you seemed to pick up on it or
were simply thinking the same thing. I question your version numbers
though. IIRC RPM Release is really for the release of the package, not the
release of the program. I would think wine-0.20001108-{RELEASE} would be
more appropriate. The release number should generally be < 1 for internal
test versions (like 0.1, 0.2) and 1 for the release and then > 1 for
bugfixes. Again, use releases like 1.1, 1.2 for internal test versions
before going to a release 2 bugfix. Looking at Red Hat's RPM's, most of
them follow this convention. After all, wine's "version number" is really
20001108. Please let's not have Wine 2000 release 1108, it's bad enough
Microsoft started bastardizing version numbers like that. :-)
One other thing. Why /opt/wine ? IIRC RedHat's standard would be
/usr/lib/wine (rpm -ql netscape-common ; rpm -ql qt for examples) although
on most other unices/distros I think you would be correct. Of course since
you made it relocatable the user does have that choice.
> However, running anything out of /opt/newwine, regardless of
> LD_LIBRARY_PATH,
> gets you routed directly back to /opt/wine. That's the sort of subtle
> thing that would cost me hours and much lost hair before I clued in to
> it.
>
Yeah, I think it was mentioned when -rpath went in that it would cause
problems like this.
Looking forward to seeing these RPMs get released, it sounds like you have
spent a lot of time pondering packaging issues and that these will finally
solve the problem of "Wine sucks, I can't get it to work." If you have not
spent some time with newbies in #WineHQ you are really missing out :-).
-Dave
