Am 09.07.2011 14:04 schrieb Stefan Tauner:
On Fri, 8 Jul 2011 11:46:38 -0700 David Hendricks dhendrix@google.com wrote:
On Fri, Jul 8, 2011 at 4:35 AM, Stefan Tauner stefan.tauner@student.tuwien.ac.at wrote:
i had the idea to implement an expiration date for flashrom binaries (i.e. a time bomb). in the case distributions ship ancient binaries (in the future) this may save a bunch of hardware.
i noted two reactions back then when i proposed this idea on IRC in my todo.txt: <twice11> If I validated software to work on some system, I don't want it to suddenly break one year later. <agaran> twice11: but kind notify that version you use is %d days old (and repeated every multiple of time or 100days or so) could be nice
Interesting idea, but I have to agree with twice11 here. I do not want a version of flashrom that works fine on the systems I'm supporting to suddenly start breaking scripts or throwing superfluous warnings to users and testers. This will definitely cause headaches for ODMs/OEMs and commercial Linux system vendors :-(
sure. when i said "it is worth to think about something like this", i meant something like the current patch, that prints a warning only. OTOH, it may still be useful to provide an option to really bail out instead of warning only (which of course would be off by default). the question is if any maintainer or individual may ever use it... if there is interest for this, i could create an add-on patch for that so we can decide its inclusion independently from the warning patch. please say so, if you think i should do that.
The issue of suddenly appearing warnings which change the user experience is not to be taken lightly.
IMHO it would be more useful to try and get generic distros to a) not include a flashrom binary by default and b) when a user installs it manually, fetch and compile sources from SVN.
providing a script that tries to mimic what the wiki installation guide tells the user to do, might be worth then? checking the availability of different package managers is quite easy, checking for the correct names shouldnt be much harder?
If anything, we should automatically build a static flashrom version for all supported architectures and platforms on each checkin, and offer those for download. That static flashrom binary should include libpci.
As for the patch itself, if this idea moves forward then it would be nice to isolate the code a bit more so it can be easily removed. Rather than placing it in print_version(), I recommend creating another function which would be called from cli_classic().
jup, certainly a good idea. "so it can be easily removed" -> do you think anyone would really want that? does it justify an option in the makefile? maybe we should "move" the OLD_MONTHS macro to the macro and add an #ifdef around the code?
What about printing the sentence only if something is marked as untested? OTOH, we already tell people to recheck with latest flashrom in that case.
carldani: the xml "parsing" is not a problem... parsing the normal svn info output would be harder. do you see a problem in the way i do it?
Would that really be harder? Normal svn output is pretty constant from a formatting POV, but with XML they can insert linebreaks wherever they want. Do you handle that correctly?
what do you think could "cause problems for users of live CDs and FreeDOS distributions" in the current implementation?
I think the current stable FreeDOS 1.0 distibution is ~4 years old. We should consider the case where people want to ship flashrom in a distribution without users bugging them about a more current flashrom release. I fear adverse adoption effects.
To be honest, I think we should postpone the decision until 0.9.4 is out (maybe even after 0.9.5). The dicussion itself is helpful, and we can hopefully build a rough consensus how the feature has to work _if_ it gets included.
Regards, Carl-Daniel