[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

    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.

 "The porcupine with the sharpest quills gets stuck on a tree more
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: