GSoC 2009 Proposal - AppDB Assistant

André Hentschel nerv at dawncrow.de
Sun Mar 22 05:58:50 CDT 2009


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.




More information about the wine-patches mailing list