From owner-freebsd-ports Sat Jan 19 10:31:51 2002 Delivered-To: freebsd-ports@freebsd.org Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by hub.freebsd.org (Postfix) with ESMTP id BDCDF37B400 for ; Sat, 19 Jan 2002 10:31:44 -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 g0JISlQ88065; Sat, 19 Jan 2002 13:28:58 -0500 (EST) (envelope-from mi@aldan.algebra.com) Message-Id: <200201191828.g0JISlQ88065@aldan.algebra.com> Date: Sat, 19 Jan 2002 13:28:44 -0500 (EST) From: Mikhail Teterin Subject: Re: depending on the shared libraries To: Alexander@leidinger.net Cc: ports@FreeBSD.ORG In-Reply-To: <200201191649.g0JGnhl11714@Magelan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 19 Jan, Alexander Leidinger wrote: >> Granted, sometimes a particular feature of a library is important and >> requiring the exact version number makes sense, but that's so rarely >> the case -- libxine worked fine with vorbis.0 and will continue >> working with .1 and probably .2... > > There was an API change between RC1 and RC2 of vorbis. Ok, but libxine can compile with either, right? >> As a result, any time I go to rebuild, say, ImageMagick, I notice it >> attempts to rebuild png, even though IM works just fine with the >> version of png I already have... > > My opinion on this: It would only make sense if we are able to specify > version ranges, e.g. "greater than .2" or something like this. I think, you can say foo.[1-46] -- it is a regexp (or glob?)... > A work around would be to use no version number until the port breaks, > but a maintainer can't test the interaction with every old version the > port depends upon. Usually -- until the software vendor note in his/her release note (or build instructions), that the new release will only work with such-and-such versions. > The actual way describes a known good dependency chain whereas your > proposal relies much more on problem reports. But it is too restrictive. And, as we see, breaks perfectly good ports, when another port is being updated (even if such breakage is easy to notice). This should be left up to the maintainer, probably, but we need another example for the porter's handbook. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message