From owner-cvs-all Sun Feb 24 15: 8: 0 2002 Delivered-To: cvs-all@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id AE35037B400; Sun, 24 Feb 2002 15:07:53 -0800 (PST) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.11.6/8.11.5) with ESMTP id g1ON7SX04508; Sun, 24 Feb 2002 18:07:29 -0500 (EST) (envelope-from mi@aldan.algebra.com) Message-Id: <200202242307.g1ON7SX04508@aldan.algebra.com> Date: Sun, 24 Feb 2002 18:07:25 -0500 (EST) From: Mikhail Teterin Subject: Re: cvs commit: ports/graphics/libwmf Makefile pkg-plist To: wollman@lcs.mit.edu, knu@iDaemons.org Cc: nectar@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org In-Reply-To: <200202211730.g1LHUqQ25415@khavrinen.lcs.mit.edu> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 21 Feb, Garrett Wollman wrote: > < 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