On the wine-users list, we're getting a lot of users who have old or even ancient .wine directories, and whose problems go away with a fresh .wine directory
Perhaps we should have wineprefixcreate stamp the version of wine the .wine directory was created with, make wine-1.0 refuse to run with pre-1.0 .wine directories, and require that future versions of wine run properly with .wine directories created by any earlier stable release of wine.
It wouldn't be hard, at least at first, and it might save a lot of support inquiries. What say?
On Sun, Mar 30, 2008 at 10:38 AM, Dan Kegel dank@kegel.com wrote:
On the wine-users list, we're getting a lot of users who have old or even ancient .wine directories, and whose problems go away with a fresh .wine directory
Perhaps we should have wineprefixcreate stamp the version of wine the .wine directory was created with, make wine-1.0 refuse to run with pre-1.0 .wine directories, and require that future versions of wine run properly with .wine directories created by any earlier stable release of wine.
It wouldn't be hard, at least at first, and it might save a lot of support inquiries. What say?
I can't find a quote of it anywhere, but I believe that a stable wineprefix was a requirement (or at least a wish) of 1.0.
On Sun, Mar 30, 2008 at 1:35 PM, James Hawkins truiken@gmail.com wrote:
On Sun, Mar 30, 2008 at 10:38 AM, Dan Kegel dank@kegel.com wrote:
On the wine-users list, we're getting a lot of users who have old or even ancient .wine directories, and whose problems go away with a fresh .wine directory
Perhaps we should have wineprefixcreate stamp the version of wine the .wine directory was created with, make wine-1.0 refuse to run with pre-1.0 .wine directories, and require that future versions of wine run properly with .wine directories created by any earlier stable release of wine.
It wouldn't be hard, at least at first, and it might save a lot of support inquiries. What say?
I can't find a quote of it anywhere, but I believe that a stable wineprefix was a requirement (or at least a wish) of 1.0.
-- James Hawkins
http://bugs.winehq.org/show_bug.cgi?id=9959
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
In the past I've had more problems with wineprefixcreate trashing my registry than I had with outdated registry entries. Especially if you have Internet Explorer or the DirectX SDK or runtime installed running wineprefixcreate has bad side effects.
On Sun, Mar 30, 2008 at 1:37 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
In the past I've had more problems with wineprefixcreate trashing my registry than I had with outdated registry entries. Especially if you have Internet Explorer or the DirectX SDK or runtime installed running wineprefixcreate has bad side effects.
We could still store the version of wine last used and issue a (gui?) warning if it's old/outdated telling the user to either run wineprefixcreate, which may be bad in some cases, or to reinstall their apps.
On Sun, Mar 30, 2008 at 4:07 PM, Austin English austinenglish@gmail.com wrote:
On Sun, Mar 30, 2008 at 1:37 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
In the past I've had more problems with wineprefixcreate trashing my registry than I had with outdated registry entries. Especially if you have Internet Explorer or the DirectX SDK or runtime installed running wineprefixcreate has bad side effects.
We could still store the version of wine last used and issue a (gui?) warning if it's old/outdated telling the user to either run wineprefixcreate, which may be bad in some cases, or to reinstall their apps.
You're missing the point of having a stable wine prefix. After 1.0, and assuming we can get a stable wine prefix, a user should never have to reinstall their apps.
On Sun, Mar 30, 2008 at 4:11 PM, James Hawkins truiken@gmail.com wrote:
On Sun, Mar 30, 2008 at 4:07 PM, Austin English austinenglish@gmail.com wrote:
On Sun, Mar 30, 2008 at 1:37 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
In the past I've had more problems with wineprefixcreate trashing my registry than I had with outdated registry entries. Especially if you have Internet Explorer or the DirectX SDK or runtime installed running wineprefixcreate has bad side effects.
We could still store the version of wine last used and issue a (gui?) warning if it's old/outdated telling the user to either run wineprefixcreate, which may be bad in some cases, or to reinstall their apps.
You're missing the point of having a stable wine prefix. After 1.0, and assuming we can get a stable wine prefix, a user should never have to reinstall their apps.
-- James Hawkins
I was under the impression that we would still possibly require a reinstall between major versions (1.0 -> 1.2, etc.). If not, then we should focus on making sure wineprefixcreate doesn't trash the registry.
On Sun, Mar 30, 2008 at 4:14 PM, Austin English austinenglish@gmail.com wrote:
On Sun, Mar 30, 2008 at 4:11 PM, James Hawkins truiken@gmail.com wrote:
On Sun, Mar 30, 2008 at 4:07 PM, Austin English austinenglish@gmail.com wrote:
On Sun, Mar 30, 2008 at 1:37 PM, Stefan Dösinger stefan@codeweavers.com wrote:
Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
In the past I've had more problems with wineprefixcreate trashing my registry than I had with outdated registry entries. Especially if you have Internet Explorer or the DirectX SDK or runtime installed running wineprefixcreate has bad side effects.
We could still store the version of wine last used and issue a (gui?) warning if it's old/outdated telling the user to either run wineprefixcreate, which may be bad in some cases, or to reinstall their apps.
You're missing the point of having a stable wine prefix. After 1.0, and assuming we can get a stable wine prefix, a user should never have to reinstall their apps.
-- James Hawkins
I was under the impression that we would still possibly require a reinstall between major versions (1.0 -> 1.2, etc.). If not, then we should focus on making sure wineprefixcreate doesn't trash the registry.
If we have a stable wine prefix in 1.0, I don't see what could possibly be added in 1.2 that would break that. The idea is that, even if you add a new dll that needs to be registered in, say, 1.0.5, you still don't need to remove your wine prefix or reinstall any apps.
On Sun, Mar 30, 2008 at 2:17 PM, James Hawkins truiken@gmail.com wrote:
If we have a stable wine prefix in 1.0, I don't see what could possibly be added in 1.2 that would break that. The idea is that, even if you add a new dll that needs to be registered in, say, 1.0.5, you still don't need to remove your wine prefix or reinstall any apps.
Can I bring the discussion back to my proposal, which was to have wine-1.0 notice old, unsupported .wine directories, and do something sensible?
Dan Kegel wrote:
On Sun, Mar 30, 2008 at 2:17 PM, James Hawkins truiken@gmail.com wrote:
If we have a stable wine prefix in 1.0, I don't see what could possibly be added in 1.2 that would break that. The idea is that, even if you add a new dll that needs to be registered in, say, 1.0.5, you still don't need to remove your wine prefix or reinstall any apps.
Can I bring the discussion back to my proposal, which was to have wine-1.0 notice old, unsupported .wine directories, and do something sensible?
If we're going to force users to remake ~/.wine, it would be ideal if we only did that once. Then we could provide some sort of upgrade path if wineprefix changed again for some reason.
I'm wondering if the case-insensitive FUSE project could be finished in time - this would allow us to both get a stable wineprefix and a case-insensitive .wine folder. This would save us the hassle of having to worry about converting case-sensitive but proper-prefixed .wine folders.
Thanks, Scott Ritchie
On Sun, Mar 30, 2008 at 3:08 PM, Scott Ritchie scott@open-vote.org wrote:
Can I bring the discussion back to my proposal, which was to have wine-1.0 notice old, unsupported .wine directories, and do something sensible?
If we're going to force users to remake ~/.wine, it would be ideal if we only did that once. Then we could provide some sort of upgrade path if wineprefix changed again for some reason.
Agreed.
I'm wondering if the case-insensitive FUSE project could be finished in time - this would allow us to both get a stable wineprefix and a case-insensitive .wine folder. This would save us the hassle of having to worry about converting case-sensitive but proper-prefixed .wine folders.
Not likely. I don't even think it's a very good idea. - Dan
"James Hawkins" truiken@gmail.com writes:
If we have a stable wine prefix in 1.0, I don't see what could possibly be added in 1.2 that would break that. The idea is that, even if you add a new dll that needs to be registered in, say, 1.0.5, you still don't need to remove your wine prefix or reinstall any apps.
That should already be the case, there's nothing magical about 1.0 that would suddenly cause that to happen. And if there are cases where it doesn't work we have to fix them before 1.0 is out. I think we should stop telling people to blow away their .wine, and have them run wineprefixcreate instead. Then if wineprefixcreate doesn't do the update correctly we need to figure out why and fix it. Once we are confident that it can do the update safely we can have it run automatically when it detects an upgrade.
On Mon, Mar 31, 2008 at 2:44 AM, Alexandre Julliard julliard@winehq.org wrote:
I think we should stop telling people to blow away their .wine, and have them run wineprefixcreate instead. Then if wineprefixcreate doesn't do the update correctly we need to figure out why and fix it. Once we are confident that it can do the update safely we can have it run automatically when it detects an upgrade.
Roger.
On Sun, 30 Mar 2008, Stefan Dösinger wrote:
Am Sonntag, 30. März 2008 20:46:08 schrieb Austin English:
My comment from the bug: "How about a little file in .wine or a registry key that is read upon running wine, and should match the current wine version. If it doesn't, call wineprefixcreate (or pop up an error saying that the registry is outdated), which then updates that key to the current wine version. Shouldn't be too much overhead and prevents quite a few problems."
In the past I've had more problems with wineprefixcreate trashing my registry than I had with outdated registry entries. Especially if you have Internet Explorer or the DirectX SDK or runtime installed running wineprefixcreate has bad side effects.
If that's still the case it's probably because wine.inf overwrites registry keys that it shouldn't and then this needs fixing. Otherwise it means we cannot do upgrades at all.
Dan Kegel wrote:
On the wine-users list, we're getting a lot of users who have old or even ancient .wine directories, and whose problems go away with a fresh .wine directory
Perhaps we should have wineprefixcreate stamp the version of wine the .wine directory was created with, make wine-1.0 refuse to run with pre-1.0 .wine directories, and require that future versions of wine run properly with .wine directories created by any earlier stable release of wine.
It wouldn't be hard, at least at first, and it might save a lot of support inquiries. What say?
I like it, since I already do something like this! How about a more surreptitious way of marking versions? Maybe a reg key or other file. This way, users might not be tempted to rename their ~/.wine and also keep the 1.0 transition smoother for scripts, say.
On Mon, Mar 31, 2008 at 11:40 PM, TheBlunderbuss tehblunderbuss@gmail.com wrote:
I like it, since I already do something like this! How about a more surreptitious way of marking versions? Maybe a reg key or other file. This way, users might not be tempted to rename their ~/.wine and also keep the 1.0 transition smoother for scripts, say.
Embedding the full version number maybe including the git ID of the source used as a string value in the Wine key should be enough.
On Tue, 1 Apr 2008, Steven Edwards wrote:
On Mon, Mar 31, 2008 at 11:40 PM, TheBlunderbuss tehblunderbuss@gmail.com wrote:
I like it, since I already do something like this! How about a more surreptitious way of marking versions? Maybe a reg key or other file. This way, users might not be tempted to rename their ~/.wine and also keep the 1.0 transition smoother for scripts, say.
Embedding the full version number maybe including the git ID of the source used as a string value in the Wine key should be enough.
Git commitids cannot be used for this purpose because they are not ordered. This means you'd have no idea if f294dda7498052dd7d3fa69d87cc539fa633217f is a pre-1.0 or not, 5 years old or a few minutes old. So you'd never know what to do / tell the user just based on the Git commitid.
So including the Git commitid is feasible and maybe even a good idea, but its only use would be for developers. Even then it would be better if it was embedded in the individual dll's version information as they may not all come from the same codebase.
-
Alexandre Julliard -
Austin English -
Dan Kegel -
Francois Gouget -
James Hawkins -
Scott Ritchie -
Stefan Dösinger -
Steven Edwards -
TheBlunderbuss