Ove Kaaven wrote:
> On Tue, 31 Oct 2000, David Elliott wrote:
>
> > One thing I was thinking of was the issue of Wine's binary compatibility,
> > especially from the point of view of codeweavers. I am assuming you are
> > doing all of this so you can setup an environment for running the programs
> > that you are porting. This may be a non-issue as i think most core issues
> > are near-finalized. However, we may want to plan for the future and allow
> > multiple copies of wine/winelib to be installed.
>
> Isn't this a problem that was solved long ago by the invention of ELF
> library versioning? In its simplest form, it goes like this:
>
> libwine.so.1.0 <= old winelib apps links with this
> libwine.so.2.0 <= new winelib apps links with this
>
> Binary compatibility was an issue that we wanted to address at Wine 1.0.
You've got a point about the ELF versioning. This indicates to me that your
method of a libwine package is a good idea. I therefore ammend my suggestion
as follows:
wine: This package should be like I said before, but should not contain the
libraries. That is, it should be the emulator and related stuff, since if you
think about it, the emulator is basically just a wine application. libwine.so
does belong in this package though, since it is only used by the emulator
AFAIK.
wine-libwine: This package should be all the libraries required to run winelib
programs.
The reason I suggest this is so that it would be possible to have several
different wine-libwines installed. If binary compatiblity is broken, an
updated set of packages will be provided, and you can still keep your old
wine-libwine package and not have file conflicts. Although unless you updated
the version of every library you'd still get file conflicts unless you package
every library seperately (which may not technically be a bad idea assuming the
right Requires: lines are used, but this could be somewhat of a PITA for users
to have to install several packages, one for each dll). Or maybe you could use
a hibrid system. Like put all of the core components in a package
(kernel,user,gdi,ntdll,libwinelib,etc.) and then have seperate packages for the
other dlls that are properly seperated in the code.
Once again Ove, you have the right idea in the first place, with these changes,
my recommendation is essentialy what you are already doing (but with different
names because of the RPM<->Debian differences).
-Dave
