Summary: | the wine ebuilds should have a wine-config | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
Component: | New packages | Assignee: | Wine Maintainers <wine> |
Status: | RESOLVED WORKSFORME | ||
Severity: | enhancement | CC: | basic, flash3001, ganymede, nt |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 61300, 57740, 66843 | ||
Attachments: |
app-emulation/wine directory contents with testing ebuild
The wine-config utility |
Description
SpanKY
![]() *** 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 attachment 44904 [details]
app-emulation/wine directory contents with testing ebuild
Created attachment 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 |