1) This is a (trivial) request for an APPDB enhancement. I would like to get a new mandatory field where to enter the hash signature of the executable you used when you submit your test results.
This would simplify to query the APPDB with a given executable and find the right entry. Notably it would also imply to have different hashes associated with the same APPDB entry (which is no issue as there may be different test results for one appdb entry anyway)
For instance (if we take sha256 instead of md5 or sha1)
sha256sum css_editor_setup.exe
outputs:
88264297495f4be1270783e37064c70a2951aabe5c5004b1feb1f1c75a9cb343 css_editor_setup.exe
It would be great to be able to find a corresponding AppDB entry for 88264297495f4be1270783e37064c70a2951aabe5c5004b1feb1f1c75a9cb343
Benefits
We have seen the advantages for this approach in the field of audio players that are able to retrieve the context data for Audio CDs from an online database. Having hashes in the appdb would also be highly beneficial for all sorts of talkback and help functions. It would also help to smoothen the different wine-bottling approaches.
For instance (just a mock interaction for a helper script):
$wineappdbcheck css_editor_setup.exe
Querying adddb for ... found
Linux Mint 17 "Qiana" x86_64 Nov 30 2014 1.7.31 I:Yes R:Yes Gold
Once a hash is in the appdb it would also simplify automated submissions of renewed test results by cli helper scripts or talkback crash reports. Such talkbacks would also simplify for developers to find out which applications used with wine calls a specific API function/stub.
2) APPDB currently does not distinguish between the installer executable and the installed app. Problems in installation are usually distinct from the actual app. Adding hashes would help to distinguish between both. the current format (installs/runs) is not very useful, as it is ambiguous.
3) Different versions of a program imply a different hash of the executable. The approach would simplify to merge different versions of the same program into one App entry, instead of the current wild approach where certain applications have separate APPdb entries for versions of the App (or even one entry for the installer and one for the app), for instance the different versions of iTunes, while others have test results per version under the same entry.
4) Submitting test results can be automated / assisted with gui, users do not have to be bothered with the hash. Hashes, Linux version, Wine version (and possible other useful information about the runtime environment/hardware) can be automatically retrieved. The existence of hash entries for a test results in the appdb would simplify test results submission. Only in the case the hash does not exist one would need manual intervention, for instance enter information for a new entry or help to retrieve the existing appdb entry to which the executable belongs.
APPDB-NG
Re: APPDB-NG
The place to file requests for AppDB enhancements is bugzilla. The product should be WineHQ Apps Database, severity enhancement.
Many users don't know what a hash signature is or how to get it, and I can tell you from experience that when forced to enter something in a field to submit their test results, users will arbitrarily select something from a list or enter garbage. If you're lucky, they'll tell you in a comment that's what they did and the test report will be rejected.I would like to get a new mandatory field where to enter the hash signature of the executable you used when you submit your test results.
Re: APPDB-NG
@dimesio
See item 4.
It is trivial because users do not need to know that. Ideally Wine run log will print the hash code. Second best is a wrapper that will do exactly that. Appdb is currently in a state where its use is too limited to be really useful. The hash concept follows the idea to enable more submissions.
It is safer to have a script run and submit
wine --version
than to let users manually enter the data because then happens exactly what you said.
See item 4.
It is trivial because users do not need to know that. Ideally Wine run log will print the hash code. Second best is a wrapper that will do exactly that. Appdb is currently in a state where its use is too limited to be really useful. The hash concept follows the idea to enable more submissions.
It is safer to have a script run and submit
wine --version
than to let users manually enter the data because then happens exactly what you said.
Re: APPDB-NG
And how do you plan to get all those hashes into the AppDB in the first place?
