Am 09.07.2011 14:04 schrieb Stefan Tauner: > On Fri, 8 Jul 2011 11:46:38 -0700 > David Hendricks <[email protected]> wrote: > >> On Fri, Jul 8, 2011 at 4:35 AM, Stefan Tauner >> <[email protected]> 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 -- http://www.hailfinger.org/ _______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
