[DOCS, POLICY] Documenting stuff that doesn't work right?
Hey, So I just blew away my previous install of Wine and reinstalled from yesterday's CVS, and went to install a program, so I could take notes on the most current user experience for the docs. I immediately realized that I hadn't run winecfg to set my drives, so I went to do that-- and that's where I ran into this problem. I was installing Icewind Dale, and like all games and Wine-installed programs, I meant to install to the partition I have set aside for that purpose, which is mounted to /usr/local/games, with a symlink in my home directory. So naturally I usually set this partition to be a Wine drive, and I prefer to use d: as the browse dialog naturally defaults to the c: drive and it's faster to change if I only have to change to the next drive. When I went to the 'Drives' tab in winecfg, I had c: (of course) e: (tmp) f: (my home directory) z: (/) You will notice that no removeable media device appears. So I go to add a drive, which is automatically called D: , as you would expect, and I set it to point to /usr/local/games, and I also add G: and set it to point to /media/cdrecorder. Hit apply and all appears well (no errors or anything of that sort). Run the IWD install again and get to the installation location section, and G appears in the browser, but D does not. Cancel and back to winecfg to try again. After several attempts, I finally opened up a file manager and went to ~/.wine/dosdevices and looked at what was there. To my surprise, there was already a link to d:, which was set to /cdrom (which is an invalid location for me anyway since I use hal, which puts stuff in /media). Since I had already set the correct mount point of my DVD drive to the g: link, I just changed d: to my preferred location of /usr/local/games, and was able to complete the install to the d:\iwd directory as I had planned. So the problem is that an automatically created (but wrongly targeted, in these days of hal/dbus) link is created to the cdrom device does not appear in the Winecfg drive list (unless you do autodetect, which may well add additional, unwanted drives to the list that the user would have to remove), making a drive letter that 'seems' to be available in fact unavailable for use (the reason that I couldn't set /usr/local/games to d was because d already existed and couldn't apparently be changed in its invisibility), and also causing the user to think that no drive letter is set for the CD/DVD device, so that they create an unnecessary second link. Obviously I know how to get around this, having just done so, but is this appropriate to document? Or is it likely to be fixed before the updated docs go 'live'? I only ask because I can't think of a way to write this up atm without explicitly exposing a flaw in Wine, and Wine doesn't really deserve that-- even winecfg doesn't deserve that, being much improved from even last month's release (which improvement is obvious, even though I've only done this single operation). I mean, I'll take notes on everything, but this looks like a policy question to me. Holly
On Wed, 2005-09-21 at 22:01 +0200, Holly Bostick wrote:
Obviously I know how to get around this, having just done so, but is this appropriate to document?
I have no idea why you encountered that sort of behavior, but it doesn't seem right. Unless Alexandre tells us this is the way it should work, I'd consider it a bug and hope that it's going to get fixed before the release. So no, no need to document it just yet. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
Holly Bostick <motub(a)planet.nl> writes:
I was installing Icewind Dale, and like all games and Wine-installed programs, I meant to install to the partition I have set aside for that purpose, which is mounted to /usr/local/games, with a symlink in my home directory. So naturally I usually set this partition to be a Wine drive, and I prefer to use d: as the browse dialog naturally defaults to the c: drive and it's faster to change if I only have to change to the next drive.
When I went to the 'Drives' tab in winecfg, I had
c: (of course) e: (tmp) f: (my home directory) z: (/)
There is something wrong here, if you are starting from a clean install you should only have c: and z:. Did you completely remove your .wine directory before trying?
Obviously I know how to get around this, having just done so, but is this appropriate to document? Or is it likely to be fixed before the updated docs go 'live'? I only ask because I can't think of a way to write this up atm without explicitly exposing a flaw in Wine, and Wine doesn't really deserve that-- even winecfg doesn't deserve that, being much improved from even last month's release (which improvement is obvious, even though I've only done this single operation). I mean, I'll take notes on everything, but this looks like a policy question to me.
Well, there's a bug here that winecfg doesn't show an existing drive, this should be fixed. And the policy at this point is to only create c: and z: by default in wineprefixcreate, the rest is done from winecfg (either manually or with the autodetect button). -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard schreef:
Holly Bostick <motub(a)planet.nl> writes:
I was installing Icewind Dale, and like all games and Wine-installed programs, I meant to install to the partition I have set aside for that purpose, which is mounted to /usr/local/games, with a symlink in my home directory. So naturally I usually set this partition to be a Wine drive, and I prefer to use d: as the browse dialog naturally defaults to the c: drive and it's faster to change if I only have to change to the next drive.
When I went to the 'Drives' tab in winecfg, I had
c: (of course) e: (tmp) f: (my home directory) z: (/)
There is something wrong here, if you are starting from a clean install you should only have c: and z:. Did you completely remove your .wine directory before trying?
Well I *thought* I had-- I renamed my current .wine directory (I have several previous renamed .wine directories in my ~/ folder; the names all start with .wine, though, such as .wine.borked, .wine.borkedmaybe, .wine.old and the like. I try to preserve the directories to preserve the Registries for reference). I also just remembered that I have a /wine directory containing a drive_c directory from a CVS install of 20050628, (which I keep forgetting to delete, but I did do an 'extra' make uninstall in the source directory before I deleted the source directory, to be sure that it was really removed). Wineinstall did not seem to think I had any previous wine directories to refer to, it made a new directory in my home folder normally, so as far as I could see, it was all all right, but perhaps it was not and this is the source of the undefined 'wonkiness' I've been experiencing latel, as this is the second time I've been told that I should only have c: and z: in winecfg, and I've *never* had just c: and z: on first run (before doing autodetect or anything, which I prefer in fact not to use and don't feel I should have to use it). What I will do is physically move all the old ~/.wine directories to another drive which I will unmount, and I will delete the bogus /wine directory in /usr/local/games (I was experimenting with the ability to put my .wine directory in a location of my choosing, and thought it might be good to have it on the same partition as the wine-installed apps, since a few apps I've run across really want to be installed in C:\Program Files, or do not let you choose, as in the case of things like Quicktime, and I don't like spreading my Wine apps across partitions if I can help it). I will then make uninstall, make clean, check to make sure that all vestiges of Wine are gone to the best of my ability, then reinstall with wineinstall and see what winecfg looks like then. Oh, and I'll catch the output from wineprefixcreate, in case there's a clue there. It will take a few hours to get to it, though, RL is making some demands, and all my current projects are backed up a bit. I'll report if any of this helps, but if anyone sees anything I've missed in my cleanup procedure, please tell me. Holly
Holly Bostick <motub(a)planet.nl> writes:
Well I *thought* I had-- I renamed my current .wine directory (I have several previous renamed .wine directories in my ~/ folder; the names all start with .wine, though, such as .wine.borked, .wine.borkedmaybe, .wine.old and the like. I try to preserve the directories to preserve the Registries for reference). I also just remembered that I have a /wine directory containing a drive_c directory from a CVS install of 20050628, (which I keep forgetting to delete, but I did do an 'extra' make uninstall in the source directory before I deleted the source directory, to be sure that it was really removed). Wineinstall did not seem to think I had any previous wine directories to refer to, it made a new directory in my home folder normally, so as far as I could see, it was all all right, but perhaps it was not and this is the source of the undefined 'wonkiness' I've been experiencing latel, as this is the second time I've been told that I should only have c: and z: in winecfg, and I've *never* had just c: and z: on first run (before doing autodetect or anything, which I prefer in fact not to use and don't feel I should have to use it).
If you are using wineinstall then that explains it, it used to do that, I have fixed it in CVS. If you avoid wineinstall and just do a configure; make depend; make you should see the expected behavior. -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alexandre Julliard -
Dimi Paun -
Holly Bostick