On 03/05/2012 10:10 AM, Riccardo Mottola wrote:
On 03/01/12 10:09, Richard Frith-Macdonald wrote:
On 1 Mar 2012, at 08:08, Gregory Casamento wrote:
The NSData archiving change is backward compatible and don't need a
new version.
The archive format is not backward compatible, but we already bumped
the archive version format to handle that.
Riccardo's problem seems to be a Gorm file with a corrupt/incorrect
archive version number somehow (it seems to have a version of 40000,
when the archive version in base has only just been bummed up to 12402).
I don't know what's going on there.
I can shed some light here:
the "4.0" version is a file version after an edit by Sebastian. So
there is soemthing strange on his gnustep version (architecture?
endianness? compiler? architecture?).
I retrieved the version before, created by me. It contains 1.25 which
was I think a temporary version of base, still equivalent to 1.23. I
edited it manually to 1.23 and it works. I will thus for now revert to
the older gorm file and patch the file manually to work around the
problem. But the bogus version of Sebastian needs to be investigated I
think.
After an off-list discussion with Fred, I think I know know where the
version 4.0 comes from. In the OpenBSD gnustep-base Ports Makefile, we
have the following statement:
pre-configure:
@perl -pi -e
's,^MAJOR_VERSION=.*,MAJOR_VERSION=${LIBgnustep-base_VERSION:R},g;' \
-e 's,^MINOR_VERSION=.*,MINOR_VERSION=${LIBgnustep-base_VERSION:E},g' \
${WRKSRC}/Version
Actually intended to set the INTERFACE_VERSION of the installed
libgnustep-base.so to libgnustep-base.so.4.0.
This also seems to have the bad side effect of changing the NSCoder
version. This is done for years now, and is already
there from before I took over the maintainership of the GNUstep ports on
OpenBSD. Since it worked well for the intended
use, I didn't cared much about it. with other ports, I usually set the
version using <LIBNAME>_INTERFACE_VERSION as a make flag when compiling.
I'll try that too with gnustep-base, just need to find some time to do so.
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.