Hm… to me it would make more sense if systemVersion was an arbitrary number that we increment only when we make a change to the archive format.
If I understand it correctly, with the current scheme, an old version of gnustep-base can't tell if it is able to read an archive or not (it doesn't know that at 1.24.2 there was a change to the archive format). If we use arbitrary numbers, incremented when a format change is made, an old version of gnustep-base can tell for sure whether it can safely read an archive saved by a newer version of gnustep-base. Eric On 2012-03-07, at 1:16 AM, Richard Frith-Macdonald wrote: > > 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. > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
