Re: RFC: some new deb package flag: "upgrade-conflicts"
>>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> On Sun, Oct 06, 2002 at 02:10:13AM -0500, Manoj Srivastava wrote:
>> >>"Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> * when is the dotrc-upgrade stuff done? (at next login
Anthony> after upgrade?)
>> How does the script running at next login (could be days) help
>> uncorrupt data?
Anthony> So, what would you suggest instead?
In the general case? I don't know if it can be done in the
general case. Even in the specific case, a simple automated solution
may not be possible. Consider a machine with multiple users using
bogofilter, with perhaps different mail handling mechanisms.
a) Since the format of the data changed, and since mail arrival on
the machine is asynchronous with regards to upgrading bogofilter,
we can't even put bogofilter in the usual place on the file system
until the data has been converted.
Since the format can't be converted until we have the new
bogofilter, we need to probably put the new bogofilter in a
non-standard location so it is available to convert databases, but
does not automatically corrupt databases of people who have not
yet converted. The people who have converted need to use the new
bogofilter.
Ideally, bogofilter should have versioned the data, and converted
on the fly, automatically. Failing that, the only way this seems
feasible is to either rename the binary (bogofilter-ng), or
schedule a flag day when the whole machine changes.
b) Since the command line has changed, people who train their data
set shall experience failures. Since there are multiple ways
people can use bogofilter, including, but not limited to,
procmail, spamassassin, mailagent ... it is not possible to auto
convert every users invocation of bogofilter (especially if you
take into account the fact that these mechanisms allow you to
import files, and I may import another users files in my own
filtering system)
Given the above, it is _not_ possible to automate the
transition. The best we can do is to make the admin aware of this,
and let the poor sould talk to hi users and create a flag day when
the databases and invocations would be changed, stop mail processing,
do the changes, intall the new bogofilter, and restart the MTA.
One should impress on the author the unsuitability flip
flopping over command line invocations and data format changes with
absolutely no care being taken to either be backwards compatible, or
to provide a transition method.
manoj
--
"The porcupine with the sharpest quills gets stuck on a tree more
often."
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: