On Fri, 8 Jul 2011 11:46:38 -0700
David Hendricks <dhendrix(a)google.com> wrote:
> On Fri, Jul 8, 2011 at 4:35 AM, Stefan Tauner <
> stefan.tauner(a)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.
> 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?
> 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?
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?
what do you think could "cause problems for users of live CDs and
FreeDOS distributions" in the current implementation?
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner