Date: Sun, 11 Oct 2009 09:49:28 -0500 From: Alex Stangl <alex@stangl.us> To: "b. f." <bf1783@googlemail.com> Cc: freebsd-ports@FreeBSD.org Subject: Re: Enforcing library version in a port Makefile? Message-ID: <20091011144928.GA94954@scout.stangl.us> In-Reply-To: <d873d5be0910102215kea9e63dj8b643f4538c124f9@mail.gmail.com> References: <d873d5be0910102215kea9e63dj8b643f4538c124f9@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 11, 2009 at 05:15:58AM +0000, b. f. wrote: > Alex Stangl wrote: > >I am trying to create a new port. The software I am trying to port uses > >scons which calls out to pkg-config to check for certain minimal library > >version #s (e.g., sndfile >= 1.0.18, libcurl >= 7). > > >I would like to enforce these same checks upfront in the Makefile rather > >than letting the build potentially blow up in scons. Section 5.7.8 of the > >Porter's Handbook says that all of the _DEPENDS variables *except > >LIB_DEPENDS* can enforce minimal dependency versions. It's not clear why > >LIB_DEPENDS is excluded here, or what the correct alternative approach > >is. It doesn't seem like putting LIB_DEPENDS= curl.5 is equivalent to > >libcurl >= 7. Hopefully there's a straightforward way to accomplish > >this, without having to patch or scrap the scons config file. > >Unfortunately I have not been able to find the answers from > >searching the net, so I hope somebody here can help. > > It's not enforced in quite the same way, but there is a check on the > version of the library if you specify it, only the check is for an > exact match, not an inequality. You can see the precise means by > which this is accomplished by looking at the lib-depends target in > /usr/ports/Mk/bsd.port.mk (beginning on line 5102 of version 1.629 > of this file). For example, > <snip> > > /sbin/ldconfig -r | /usr/bin/grep -vwF -e "/usr/local/lib/compat/pkg" > | /usr/bin/grep -wE -e "-lblas\\.2" > > which is version-specific. Probably an inequality check was not > implemented because libraries with different major versions are > expected to have different and incompatible ABI/APIs. The > corresponding version numbers of the port as a whole are not usually > relevant for LIB_DEPENDS, only the version of the shared library > itself, as the upstream maintainers are supposed to change a shared > library version if and only if they change the API/ABI of the library. It seems like there are 2 numbering schemes for shared libraries: 1. Version stored in /usr/local/libdata/pkgconfig/*.pc (same as PORTVERSION?) 2. Major version number stored as part of the library filename. I realized I could check for exact match for #2 (mentioned LIB_DEPENDS= curl.5 in my message), however I would like to ideally check for #1 since that's what the scons config seems to be looking at. It seems like checking #2 is only a rough proxy for #1 and is likely to make for a fragile port. For instance, say scons config is checking for >= X.Y in scheme #1, but all I can do is put a check for M in scheme #2. Then we have these problematic scenarios: 1. If there are versions of the lib.M that have version #s in scheme #1 less than X.Y, then the build will fail in scons, leaving the user confused and unhappy. 2. If user upgrades ports and gets lib.M+1, make fails because the exact match is no longer satisfied. (Porter's Handbook says you can use LIB_DEPENDS regular expressions like curl.[5-9] so this shouldn't be as much of a problem, at least not until it breaks years later on curl.10) > If you are relying upon some feature of a port that may change while > it's relevant shared library versions remain the same, then you should > add the port to the other *_DEPENDS as needed, with appropriate checks > on the port version number in those variables. I suspect this is what I shall have to do. Is this what all other port authors do in similar circumstances? It seems kind of a hackish workaround, especially if the library in question doesn't have a corresponding executable to list in RUN_DEPENDS. Do I force a library name into RUN_DEPENDS? It would be nice to be able to express the real dependency as precisely and accurately as possible, say I want >= X.Y (in numbering scheme Z) of this library, rather than have to obfuscate intent by using some proxy. Thanks for the response! Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091011144928.GA94954>