dumb
dumb copied to clipboard
kode54
New release ?
The 1.0 release is over two years and a half old at the time of this writing. Since then, there have been various fixes and improvements which are useful to Linux distros, e.g. Allegro 4 support. And usually, distros would rather package releases than versions directly from the SCM :)
Before making a release, maybe the README should be updated to mention the new capabilities of this continuation of the original DUMB library still available from SF.net ?
If there is a new release I would like to update the package in Debian to use it. But this requires that the library follows the rules regarding its soname (library version). Right now the soname is set to 1.0 (for libdumb 0.9.3 we used 1.0.0 in Debian). This would imply that the library interface didn't change at all and in particular that programs using libdumb don't need to be recompiled for this update. Is that the case?
For more on updating the soname see https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
Right now the soname is set to 1.0 (for libdumb 0.9.3 we used 1.0.0 in Debian
If I remember correctly, there are some ABI-changes between 0.9.3 and 1.0.0 (I remember at least one added parameter).
And I also got concerned, when #36 was merged and saw that Debian used libdumb1 and not libdumb0. What would be a solution? Call the next version 2.0.0 to keep binary compatibility? Alternatively one could have a look into what has changed exactly and whether it is possible to write wrappers.
@akien-mga
Debian used libdumb1 and not libdumb1? Did you make a typo?
There is no need to write wrappers or anything, just to choose a correct library version for every release. This is important because distributions decide based on the soname if they need to rebuild other software which uses the library.
How to choose the library version is described in the link I posted above. Given that the source code changed, it should be either 1:1:0, 1:1:1 or 2:0:0 depending on how the interface changed.
I did make a typo (and corrected it). I was thinking about cross-distro-compatibility, but I guess that ship has sailed.
Ah, maybe in the past distributions picked their own sonames because the dumb developers didn't do it. If we have to rebuild it would be nice if the official soname could be 2 to avoid a conflict in Debian.
A 2:0:0 would be best for the changes I've made to the filesystem API implemented in the library, as it now supports full seeking, so implementations will need to keep that in mind. It really simplified things in some of the format parsers. Especially MOD, which originally implemented a buffering reader just to skip ahead to the signature bytes, then used the buffer to re-read the header data.
The question that needs to be answered to decide about the new soname is whether binaries compiled against libdumb 0.9.3 work with the current libdumb 1.x without being recompiled. Whether or not there are new features that implementations may use is only of interest to decide between 1:1:0 and 1:1:1 if the ABI stayed compatible. But I guess it may be safer to go with 2:0:0 and recompile after this much time and many changes.
Recompilation is necessary, unless the code doesn’t touch the file interfaces, such as by registering the stdio system and using the “load” API instead of supplying your own filesystem or using the supplied readers manually with the typed “read” API.
