Bugzilla Bug 9842

along the same lines of java-config, provide symlinks/environment variables for 
libraries/binaries/headers 

env.d entries for LDPATH (somethings use libraries to link against) 
env.d entries for PATH (somethings use 'winebuild' to compile) 
symlinks in /usr/include/wine (updated by wine-config) 

think thats all ...

*** Bug 11731 has been marked as a duplicate of this bug. ***

it needs some general wine* ebuild changes, reassing it to me if nobody wants
it/ the wine mantainer won't come up, atm I don't have the time to plan and
make such changes.

well, looks like I am going to be the wine maintainer. 
I am on it. 

*** Bug 55132 has been marked as a duplicate of this bug. ***

Yes, I think that's pretty right - the wine ebuilds should have a wine-config,
indeed -, and I promise to look into that issue ASAP. For the impatient, I have
some time ago written  (and am still maintainig) a perl-based wrapper to wine
that in addition to a similar functionality as the one asked for in the bug
report also provides efficient logging of the debug output, and can be found
here[1]. 

[1] http://www.david-guembel.de/winestart.html

Is there someone actively working on this? I would like to look into that over
the weekend, so maybe it would be wise to share.

BTW, is there someone (non-odentical to me) who would be willing to test?

of course, i'm willing to test.

i'd suggest you use 20041019-r3 as your base ...

transgaming / cedaga SLOT themselvess pretty nicely already, would be just a matter of handling the wrappers with them

wine would have to install into ${P} directories (/usr/share/${P}/) and then have the wine-config modify $PATH and $LDPATH like gcc-config does with gcc

hope that helps :)

Created an attachment (id=44904) [details]
app-emulation/wine directory contents with testing ebuild

Created an attachment (id=44905) [details]
The wine-config utility

OK, here is a first version of the wine-config utility. I have based my work on
gcc-config. To test, you'll need to do the following:

* download the wine.tar.gz tarball and extract it into your PORTAGE_OVERLAY.
The tarball contains a app-emulation/wine/ directory with a wine-20041019-r4
ebuild that creates a profile entry for itself in /etc/env.d/wine/

* download wine-config and place it somewhere inside your PATH. I am yet to
make an ebuild for that tool, and add it to the dependencies of the new wine
ebuild. JFTR, the md5sum for wine-config is e1c6c31685cf7510468fdc616bafb1ae.

Now 
1. emerge wine-20041019-r4.ebuild
2. run "wine-config wine-20041019"

The relevant files for wine-config are in /etc/env.d/wine/. In that dir, after
you used wine-conf to set the profile, there should be a file "config" and a
file "wine-20041019". After having run wine-config, you'll have to do the
usual: env-update && source /etc/profile.

Wine should have installed itself into /usr/share/wine-20041019/. After a
profile has been specified with wine-config, you should also have an
/etc/env.d/99wine, and the dir /usr/share/wine-20041019/lib should appear in
/etc/ld.so.conf.


Things I didn't do yet (more or less a reminder for me ;)
* the einfo stuff in the ebuild is not yet great. 
* set the emerged version as default profile if no default profile exists yet
* maybe extract the wine-conf specific stuff into an eclass
* look into the other wine-related ebuilds (cedega, crossover,..) and apply the
changes there as well

Happy testing ;)

well... seems to work fine. now all we need are some different wine versions
that can co-exist and are not deleted by a casual "emerge -Du world". usually
older versions get delted from portage after some time. but if i want some wine
version from some day last year? sometimes it happens, that certain
games/programs work only with certain wine versions...

i'm not sure if it is still possbile/needed that we run more than one wine
version with wine-20041019-r3

why not? is it perfect? i doubt that.

Given the lack of work on this bug in the past 11 months, I'm requesting this
bug be closed or worked on.

For the record, I think multiple wine installs would be useful...I just use
quickpkg with various wine builds, myself. :)

i dont think this would be useful anymore seeing as how wine has moved out of
'cvs snapshot' mode and into 'release' mode