![[BACK]](/icons/back.gif){kind=icon}
Up to [local] / src / lib / libskey
Request diff between arbitrary revisions
Default branch: MAIN
Current tag: OPENBSD_2_8_BASE
Revision 1.9 / (download) - annotate - [select for diffs], Tue Jul 29 09:28:22 1997 UTC (26 years, 10 months ago) by niklas
Branch: MAIN
CVS Tags: OPENBSD_2_9_BASE,
OPENBSD_2_9,
OPENBSD_2_8_BASE,
OPENBSD_2_8,
OPENBSD_2_7_BASE,
OPENBSD_2_7,
OPENBSD_2_6_BASE,
OPENBSD_2_6,
OPENBSD_2_5_BASE,
OPENBSD_2_5,
OPENBSD_2_4_BASE,
OPENBSD_2_4,
OPENBSD_2_3_BASE,
OPENBSD_2_3,
OPENBSD_2_2_BASE,
OPENBSD_2_2
Changes since 1.8: +2 -2 lines
Diff to previous 1.8 (colored)
This case of version number update is a little special and was not well-known before. A new general rule has been formed: When you change a library to *use* a new API of another library (which may there only have given need to a minor number crank), you must crank the *major*. The specific scenario that was seen this time was: I libc 16 started without the SHA interface II libskey 0 did obviously not use it III installation of libc 16 and libskey 0 IV software installed that uses libskey V libc 16 got SHA added, minor number update VI libskey 0 was changed to use it VII libc was cranked to 17 for other reasons VIII installation of libc 17 and newer libskey 0 IX use of the software installed in IV fails! This is due to the fact that the libskey using software searches for the most current libskey 0, which uses the SHA interface, and the most current libc 16 which was the old one installed in III, which does not provide SHA, and thus gets two incompatible libraries linked with it. Crash! One could argue that people should install all library versions that is made available, but that is really not feasible. One have to recognize that people may build their systems at arbitrary points in time and then go on to install software they know work at their lib revision levels. A later build should not break this software, that may only be available in binary versions.