On 2023/02/12 00:45:38 +0200, Hannu Vuolasaho <[email protected]> wrote: > Hello porters, > > This may be a silly question. The porters handbook and bsd.port.mk man page > suggest that version is set to 0.0 and then it is incremented as software > develops and so on. This stuff I understand. > > As far as I dig information, the libraries are then installed as > libfoo.so.0.0 and to get this working is matter of testing and fidling the > build process. > > Now comes the tricky part. Someone finds a bug. It gets fixed in svn
hopefully it won't only "get fixed in svn" but upstream will do another release. > and > when I set the library version to wrong number, consumer says the library > is incompatible. And this is sane thing. nope. the "library version" in the file name is only about its API/ABI history. it is not the "project version", even if some upstream now are using it for that. Let's say we import the package foo-1.0 today that provides the library libfoo.so.0.0. Then, upstream fixes some bugs and releases foo-1.1; we update the port and, say, since upstream added a few more functions, the library is bumped to libfoo.so.0.1 So what? 0.0 or 0.1 are not the "version". 1.1 it is. if you want to make sure you're linking to a "bug-free" version you should check the *package* version. > Using old and broken library is > stupid, loses work and makes you angry. But for the finder of the bug, the > ported library is useless. yes, as it should be. for the finder of the bug, the _package_ version is the thing to look at. > And the bug fix stays untested. After that I > would get the blame of broken package. I don't think so :) Btw, the entire ecosystem works in terms of "package version" and not "shared library version". (this also because a single package may provide more than one library.) Stuff like portroach or repology looks for potential outdated packages by comparing their versions (in the case of repology this is done across several package repositories). In all of this, the shared library version is _never_ taken into account. It could be 999.99 for all you care. it is not, by any means, a "version number" as an end user may initially think. it's just a number to tell the linker whether a given program linked against libfoo.so.X.Y will work with libfoo.so.A.B > When I work on the port side of the consumer programs, I can take care of > this problem. However how to handle the non-ported build? I don't think this is a problem at all. However, when you manually install stuff you're of course free to do as you please. using a different versioning scheme should work. (although i'd not suggest to install stuff outside the ports tree, but that's just me :-) > And there are no unportable things like GNU or libtool. Maybe pkg-config in > configure as fallback for dependencies. I'm not sure I got what you're referring to here. FWIW pkg-config works with *package versions*, not shlib ones. > And if someone is interested, I'm working on Ringdove suite. Librnd, > pcb-rnd, camv-rnd and sch-rnd. > > Best regards, > Hannu Vuolasaho > > P.S. What the comment on SHARED_LIB line means? the comment is to indicate shlib version used by upstream.
