Wojtek Kubiak wrote:
On Sunday 01 April 2007 09:53, you wrote:
Wojtek Kubiak wrote:
Package: wine
Version: 0.9.31-1
Severity: minor
--- Please enter the report below this line. ---
Wine puts the file wineserver in a location (/usr/lib/wine/) that is not
added by default into the systems PATH. This leads to conflicts with
several applications which rely on the fact that one of wine's components
(wineserver) can be found in the PATH (like /usr/bin/ for instance). If
it cannot be put there physically, a symlink could be created by the
package.
And what applications are these?
Well, for example winebot (http://winebot.sandbox.cz/ ). At first I filed a
bug report there and the answer was that the debian wine package puts the
wineserver application not in the same location as the wine projects binary
packages ... Why is it like that?
Well, because I don't think wineserver should be in the PATH. It doesn't
make sense to have it in /usr/bin. It's not something a user needs to
start directly (unless they're doing some weird hacking, in which case
they should be knowledgeable enough to use the full path to the binary
anyway). It's a daemon. System-wide daemons live in /usr/sbin, which
isn't in a regular user's PATH either. It's started and shut down
automatically by the main wine process. If they need to know, Wine's
child processes can tell where it is based on the WINESERVER environment
variable, which is set in the winelauncher wrapper, but they shouldn't
need it.
This also permits several independent wines and their servers to exist
on the system; the user can install and select between various Wine
versions, with no risk of accidentally invoking a different version's
binaries because of any directory in the PATH being polluted. I think
CodeWeavers once provided relocatable RPMs which would do something
similar. Perhaps they still do. Anything that depends on wineserver (or
maybe even wine) being in the PATH would break on such a relocated RPM.
No reason such bad programming should be working better in my Debian
packages. And they have the advantage that once Wine gets a stable
branch, it will be possible to create packages from both the stable and
unstable branches of Wine, that will be able to coexist on the same
system. Presumably, the user would be able to run some apps with the
stable Wine and others with the unstable Wine simultaneously, if there's
no wineserver conflict. As long as it's kept out of the PATH, there
won't be such a conflict.
So, IMO, depending on the wineserver being in the PATH is just sloppy
programming. Wine's own source code makes it possible and easy to put
the binaries wherever you like (even without recompiling them), and for
good reason; it's silly to require that nobody use this ability. And
it's not clear to me why any app even needs to know where it is...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
