[flashrom] [PATCH] warn the user if flashrom is x months old

[Carl-Daniel Hailfinger]

Am 09.07.2011 14:04 schrieb Stefan Tauner:
> On Fri, 8 Jul 2011 11:46:38 -0700
> David Hendricks <dhendrix at google.com> wrote:
>   
>> On Fri, Jul 8, 2011 at 4:35 AM, Stefan Tauner 
>> <stefan.tauner at 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

-- 
http://www.hailfinger.org/