cvs commit: ports/databases Makefileports/databases/libmemcache Makefile distinfo pkg-descr pkg-plist

[Doug Barton]

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
>>>>>files.
>>>>>  I haven't dug into this too much beyond noting there's a problem.
>>>>>-sc
>>>>
>>>>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.

Doug

-- 

	If you're never wrong, you're not trying hard enough