Re: [gentoo-dev] small dispatch-conf patch, WAS: extension of etc-update

[Radoslaw Stachowiak]

> > Because You have to calculate them for all files, and _before_
> > emerge. Also such database has to be regularly updated (sth like
> > eupdate/esearch).
>
> Hmm, I thought that things were only calculated/compared for those
> configuration files which might involve updating (those that get ._cfg etc)

yes, you are right. i was talking only about CONFIG_PROTECT files.
the biggest problem (as I see it) is that it requires special
maintenance and overhead to gather this data constantly. of course
computational overhead (due to use of md5) is negligible.

> > Not that Im sure of time approach, but Could You show one real word
> > scenario when ctime/mtime comparison would fail /while md5sum does
> > not/ ?
>
> In cases of clock skew or toying with touch. Esp. the clock skew thing is not
> that uncommon.

Hmm, good point, but skew must be backwards, and not only it have to
be big enough (which is hard to achieve because every second after
package installation time, this necessary-for-failure time gap is
growing), but it has to be present at the time you hand modify
config-file-to-be-lost. i think its almost impossible.

Of course ntp time synchronisation would solve this.

As to touch. normal touch usage don't put You at risk because file
will have mtime > ctime so its not problem. special touch usage
(modify mtime to value other than current) is so rare that have to be
use for some purpose (eg for mark file to be overwritten by newer
update, even ifits modified) which is justified use for me.

Files overwritten are backed up by dispatch, so even if sth was
screwed up, you can get previous file from dispatch backup.

Im going to use it on some  machines this month, and will let You know
what happened :)

-- 
radek@g.o.

--
gentoo-dev@g.o mailing list