Date: Sun, 24 Feb 2002 18:07:25 -0500 (EST) From: Mikhail Teterin <mi@aldan.algebra.com> To: wollman@lcs.mit.edu, knu@iDaemons.org Cc: nectar@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: ports/graphics/libwmf Makefile pkg-plist Message-ID: <200202242307.g1ON7SX04508@aldan.algebra.com> In-Reply-To: <200202211730.g1LHUqQ25415@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21 Feb, Garrett Wollman wrote: > <<On Thu, 21 Feb 2002 11:16:40 -0600, "Jacques A. Vidrine" <nectar@FreeBSD.org> said: > >> I'm not sure that applies to the packages upon which libwmf depends. >> But even if it did, it is still foolish to ignore the version >> numbers. One doesn't know whether the major version was bumped >> gratuitously or not. As stated before, this is done to make it easier (possible!) to build the port against an earlier (or, perhaps, later) version of another port. > Well, remember also that the library version number indicates *binary* > compatibility; what the ports, in general, are interested in is > *source* compatibility, and the library version number does not > necessarily help at all there. Exactly my point all along. A library may not be used as a binary replacement of its earlier version, but it will usually work just fine as a source replacement -- if the library using software is recompiled using the new versions of the headers, essentially. The cases of source incompatibility are MUCH more rare than those of the binary. (And the later are don't happen as often as the major version bumps, but that's an unrelated topic.) And yes, a new release of a library may finally break the depending port, but this will not happen as nearly as often as the "chase the major number of the -lfoo" commits. The only counter-arguments so far are, that my changes may break the package collection (they may not, since Bento uses the latest versions of the packages anyway) and/or they break one of the possible readings of the Porter's Handbook (those "chasing" commits don't raise the PORTREVISION, typicly, either). Someone also mentioned, they may break the usage of portupgrade, but I don't see how, and even they can, I suspect, this would be a portupgrade's problem. After all, ports are primary. Packages are secondary... Portupgrade is not even in the base system (although it is a known and important port). > (Binary compatibility for packages being taken care of by the package > versioning, which is oblivious to the shared libraries inside.) That's my understanding too. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202242307.g1ON7SX04508>