Packages that change without incrementing the version/release

[Max Bowsher]

Christopher Faylor wrote:
> On Fri, Nov 19, 2004 at 12:27:47PM -0000, Max Bowsher wrote:
>> Anyway, this means many users are likely to have old 'invalid' versions 
>> of
>> these packages. Which means, that before I can release a new setup, I 
>> need
>> to make setup recover gracefully, rather than exiting at the first error 
>> as
>> it currently does.
>
> Different sizes should be irrelvant.  The MD5s will not match between the
> package disk and the one in setup.ini.  Doesn't that force a re-download?

Currently, setup more-or-less ignores incorrectly-sized files - i.e. does 
nothing, not even flagging their invalidity to the user. In download mode, 
that might trigger a re-download without notification as to why it is 
happening. In install-local mode, it causes an internal error in setup in 
some cases - or even leads to silently abberrant behaviour - like installing 
the source package instead of the binary!

>> Currently I'm thinking along the lines of having setup rename the package
>> files as it finds them, adding a ".BAD" suffix. As far as user feedback
>> goes, I will probably go with a MessageBox summarizing all the problems 
>> at
>> the end of the scan, for a short term quick hack to get a new setup out
>> ASAP. Later though it should become a scrollable log textfield.
>>
>> Comments on the above?
>
> The more feedback we can provide to the user, the better.

Right.

And one important consequence of this is that packagers must *never* change 
files without changing the release number, once they have gone to the 
mirrors - because setup.exe will be telling users that something odd has 
happened - not just silently ignoring the inconsistency.

Max.