Date: Wed, 7 Nov 2012 21:09:14 +0200 From: David Naylor <naylor.b.david@gmail.com> To: "Thomas Mueller" <mueller23@insightbb.com> Cc: freebsd-ports@freebsd.org Subject: Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64) Message-ID: <201211072109.17279.naylor.b.david@gmail.com> In-Reply-To: <58.E1.17144.7AD2A905@smtp01.insight.synacor.com> References: <58.E1.17144.7AD2A905@smtp01.insight.synacor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart5029831.DrpDVSuhQ6 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Wednesday, 7 November 2012 11:45:11 Thomas Mueller wrote: > from David Naylor <naylor.b.david@gmail.com>: > > Hi List, > >=20 > > # Executive Summary > >=20 > > Over the past years I have been maintaining the wine-fbsd64 port (see > > http://mediafire.com/wine_fbsd64 for more). The port itself effectively > > does static linking (it bundles all the libraries wine needs) with > > scripts to bootstrap the environment to easily use wine from > > FreeBSD/amd64. There is also a script to install the i386 nVidia > > graphic drivers so that wine has access to nVidia accelerated graphics > > from FreeBSD/amd64. > >=20 > > I would like to propose this port gets included in the port's collection > > and would like to get feedback, your comments please :-). > >=20 > > P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the > > discussion. > >=20 > > # Conclusion > >=20 > > "It is based completely off the main port and uses the hack to, > >=20 > > effectively, use static linking (or bundling of libraries). In a > > sense it is a complete, yet quite stable and encompassing, hack. " > > - David ;-) >=20 > It would be nice to have wine-fbsd64 as a port, but that might > unfortunately deprive the user of certain flexibility. To what flexibility do you refer to? Nothing stops the user from building = the=20 port herself and for those who prefer a binary with most options switched o= n=20 (as is with what I provide) that can still be provided (and possibly in an= =20 automated manor via a pkgng repository). =20 > Also, nVidia support should be an option, since users with other graphics > cards might have no use for it. I think I fail to explain how the nVidia support works: it is a simple scri= pt=20 that downloads the corresponding i386 drivers (user land libGL stuff) for t= he=20 amd64 package. If there is no amd64 package installed it cannot know which= =20 i386 version to download, also, when installing it does not download any=20 files, only installing the drivers if the distfile is already available on = the=20 system. =20 So, there are three cases (on installation): 1) The user has no amd64 package installed (nothing is done) 2) The user has amd64 package installed but no i386 distfile available=20 (nothing is done) 3) The user has amd64 package installed and i386 distfiles available (user= =20 land libGL stuff is extracted and placed in $LOCALBASE/lib32) In case 2, the user is advised to run the script manually to download and=20 install the i386 distfiles. =20 In cases 1, 2 and 3 the user is advised to run the script manually whenever= =20 there is a change (or installation) to the amd64 package. =20 > I would really prefer to build the i386 FreeBSD system as a separate part, > including kernel, since some users, myself included, might want to run an > actual FreeBSD i386, especially on an older computer. So one could build > this FreeBSD i386 on a USB stick or USB hard drive, and then be able to > run wine on an i386 system. I think an "easy" way to achieve this is to modify the FreeBSD32 compatibil= ity=20 to work similar to the linux compatibility, namely: have a super-imposed=20 "shadow" file-hierarchy at /compat/i386 (similar to /compat/linux). This w= ay=20 the i386 packages can be installed into /compat/i386 and when called can=20 easily find the correct libraries. =20 Then, create an alias: pkg-i386 =3D chroot env UNAME_p=3Di386 UNAME_m=3Di386 MACHINE=3Di386 /compa= t/i386 pkg and with the correct i386 repo specified it is trivial to install i386=20 programs and with a modified PATH: PATH=3D$PATH:/compat/i386/usr/local/bin:/compat/i386/usr/local/sbin the programs will integrate seamlessly. =20 However, to my knowledge, there are few ports that are i386 only (such as=20 wine) and maybe it is easier to use a similar "hack" to the wine-fbsd64 por= t=20 to cater for the fringe cases??? P.S. I really would like to see FreeBSD be broken into packages and integra= ted=20 into the ports tree, just my crazy ideas though... > Would wine-fbsd64 be a separate port, or would it be wine built on i386, = as > the page http://wiki.freebsd.org/Wine suggests? It would be nice to be > able to run Wine on i386 as well as amd64. The answer is yes to both your questions. It can only be built on i386 but= is=20 a separate port. The reason for the separate port is to allow extra "stuff= "=20 to happen so that it can be run on amd64 as well. The package can be run o= n=20 both i386 and amd64. =20 Regards --nextPart5029831.DrpDVSuhQ6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEABECAAYFAlCasd0ACgkQUaaFgP9pFrLonQCdEm8VjMNzrvQWBKS9pPFJqbQw 7eUAn3KqUI/boQphHURzW9e1JeKZ7PWc =fJAS -----END PGP SIGNATURE----- --nextPart5029831.DrpDVSuhQ6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201211072109.17279.naylor.b.david>