Ben Klein schrieb:
Grabbing the version number of the application from the EXE metadata could prove to be unreliable. A lot of Windows apps don't include metadata, or include unusual values in the metadata. Then again, a lot of apps don't make it easy to see what the version you're using is in any other way, and as a result there are a lot of "1.0" versions on AppDB that map to "initial retail version".
One example is Theme Hospital, which as the original retail version was released as "Beta 4", and Bullfrog provided a patch that upgraded to "Beta 5". The only hint of version numbers is provided by the patch itself, and as a result some user wanted to submit a "1.0" version to indicate the original retail release. As I was a supermaintainer of Theme Hospital and already had the "Beta 4" version, I removed the 1.0 version and engaged in a lengthy email discussion over whether the retail release was "Beta 4" or "1.0".
I am also afraid of reading this data, but we could give the user the choice to review it and correct it.
There has been discussion about "preconfiguring" Wine with AppDB data, and the general consensus is that it's a bad idea. We run the risk of becoming like wine-doors, playonlinux, and other tools we don't support at WineHQ. The biggest problem is that there is no way to determine if any particular configuration will still work when a new version of Wine or a new version of the app is installed. There are also cases where installing a workaround/native DLL for one app will cause a whole lot of others to break.
It is a hard discussion, so lets have it when we got the AppDB Assistant running ;)
No, really, the basic idea is great, but we don't should do all at once. For GSoC i think the best parts are the basic software implementation and the communication to the server.
-
André Hentschel