Date: Wed, 01 Dec 2004 13:12:36 +0200 From: Doug Barton <DougB@DougBarton.net> To: Michael Nottebrock <michaelnottebrock@gmx.net> Cc: ports-committers@freebsd.org Subject: Re: cvs commit: ports/databases Makefileports/databases/libmemcache Makefile distinfo pkg-descr pkg-plist Message-ID: <41ADA724.7030809@DougBarton.net> In-Reply-To: <200411301129.41752.michaelnottebrock@gmx.net> References: <200411300909.iAU99RI6078889@repoman.freebsd.org> <074899D0-42B3-11D9-9C6A-000A95C705DC@chittenden.org> <1101808328.38078.12.camel@pav.hide.vol.cz> <200411301129.41752.michaelnottebrock@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41ADA724.7030809>