cvs commit: ports/databases Makefileports/databases/libmemcache
Makefile distinfo pkg-descr pkg-plist
DougB at DougBarton.net
Wed Dec 1 03:12:42 PST 2004
Michael Nottebrock wrote:
> On Tuesday, 30. November 2004 10:52, Pav Lucistnik wrote:
>>Sean Chittenden pí¨e v út 30. 11. 2004 v 01:34 -0800:
>>>>>2) pkg_version seems to want to shorten libmemcache.so.1.0 to
>>>>>libmemcache.so.1, which is rather broken.
>>>>>I'm using the @unexec directive as a workaround, but it appears as
>>>>>though there's a problem with pkg_version's parsing of pkg-plist
>>>>> I haven't dug into this too much beyond noting there's a problem.
>>>>That's not a bug, that's a feature. We don't do libfoo.so.X.Y on
>>>>FreeBSD, we do libfoo.so.X only. Please fix your software :)
>>>Yikes! You're probably not joking... but could you be? Please?
> It's not really a feature. It was introduced to help with the a.out->elf
> transition, reasoning being that elf shared objects don't really _require_
> the complete versioning to be represented in the filename and they'd be easy
> to distinguis from a.out libs with x.y.
> However, the a.out days are past long enough now to seriously consider
> allowing elf shared objects to have more freefrom (and possibly more
> meaningful) names again (just like on that other OS). The main reason we're
> getting away with our funny naming for elf shared objects so easily in ports
> is that libtool deals with it for us.
I agree that it's time to revisit this. I've already run into a cockup with
windowmaker because a bad library bump was applied in FreeBSD's port to get
around the fact that they use libfoo.N.N.N.
If you're never wrong, you're not trying hard enough
More information about the cvs-ports