2009/3/22 Illya Klymov illya.klymov@gmail.com:
So, let's imagine we have a software which I call "AppDB Assistant" with following functionality:
There has been quite some activity on wine-devel recently regarding the AppDB, including a few ideas on how to automate uploading information or configuring Wine based on AppDB entries.
- an ability to quickly submit a report about application to AppDB. A lot
of data (Wine version, Linux distribution, wine settings) could be obtained automatically. An application information with high probability could be fetched from meta data, stored in EXE file. In general, i see that like after closing an app I see additional screen "Please take a couple of seconds and send feedback about your experience with $SOFTWARE_NAME to AppDB", and buttons "Platinum","Gold", etc. Of course this should be configured via winecfg (if user do not want to obtain such data)
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".
- an ability to generate a "configuration guide" - in this mode an "expert
user" selects important data to be included into a guide (for example that app runs _only_ under Windows XP emulation, an important registry values etc.). As a result a special file, describing an app-specific configuration of wine is uploaded to appdb 3) an ability to "preconfigure Wine". That means that based on "configuration guide" created on step 2 "AppDB Assistant" can configure wine in one click. If any additional dlls are required a warning message is displayed with possible information where to obtain them.
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.
I see the following benefits on such software:
- increasing appdb actuality - with a way more data from users we can
provide more accurate info; 2) simplified regression testing - for example if user downloaded a "configuration guide" and it didn't work with newer wine - this is a possible regression (decreased chance of human error)
Regression testing is *only* useful if there are no native DLL overrides configured. Test data submitted using a set of pre-configured overrides is nowhere near ideal for Wine.