Re: [Gnustep-cvs] r34822 - in /libs/base/trunk: ChangeLog Source/NSData.m

[Richard Frith-Macdonald]

On 6 Mar 2012, at 09:32, Fred Kiefer wrote:

>> 
>> There don't seem to be anyone using Gorm on OpenBSD from the packages.
>> I'd guess, otherwise, the problem would have shown up much earlier.
>> Therefore I'm not sure, whether there is a real need to fix that in
>> -base. But I definitely
>> should fix it in the Ports/Packages.
> 
> I think you are wrong here. The mismatch of the archive numbers could not 
> have caused any problem before the change to NSArchiver. This means, we don't 
> know if any gorm files or other archives made on OpenBSD are affected. We 
> have to plan for the worst and try to come up with a solution that allows for 
> these archives to be read in correctly.
> 
> I would like to propose an over cautious solution: We decouple the archiver 
> systemVersion from the library version and make it bigger than any number 
> already used on OpenBSD, lets say, library version + 4 (= 5.24.2). And make 
> this the version that gets special treatment in NSArchiver, plus of course 
> 1.24.2 (hopefully this specific number hasn't been used on OpenBSD), as we 
> already have new archives produced with that number. And on OpenBSD, we need 
> to guaranty that such mixing of version numbering never happens again.
> We also need to investigate the whole base code, whether there is another 
> place where we might have such a mix.

I've been thinking about this ... I really don't like the idea of separating 
the value returned by -systemVersion from the version of the system ... it just 
seems wrong.

This is simply a bug in the OpenBSD  package, nothing to do with GNUstep 
directly ... but we ought to do a workaround.

What I'd suggest is a temporary hack (meaning we should remove it in a few 
years) to recognise version 4.0.0 as actually meaning 1.24.1 unless the current 
system version is 4.0.0 or later, so that decoding old archives works (though 
we should probably report the incident using NSLog()).

Given that our version numbering increases really slowly,  I wouldn't expect us 
to actually get to version 4.0.0 for several years, by which time old OpenBSD 
specific archives should not be an issue.