Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 02 Aug 2002 13:39:05 +0300
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        Will Andrews <will@csociety.org>
Cc:        Dag-Erling Smorgrav <des@ofug.org>, ports@FreeBSD.org
Subject:   Re: Bug in pkg_add?
Message-ID:  <3D4A6149.1054DFF7@FreeBSD.org>
References:  <xzpr8hk41jr.fsf@flood.ping.uio.no> <3D47D344.8E23AECF@FreeBSD.org> <20020731130208.GH52296@squall.waterspout.com> <3D47F933.31C553E8@FreeBSD.org> <20020731150600.GL52296@squall.waterspout.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Will Andrews wrote:
> 
> On Wed, Jul 31, 2002 at 05:50:27PM +0300, Maxim Sobolev wrote:
> > > Such things are usually symlinks, not the actual shared library,
> > > and are occasionally used for configure scripts to detect the
> > > version installed (a valid usage IMHO).
> >
> > You are not quite correct. Shared libraries with embedded version
> > number look like libfoo-X.Y.so.Z, format libfoo.so.X.Y is relict from
> > the aout days and doesn't have any other meaningful purpose today.
> 
> No, I am correct.  You are right in that it *was* used for aout
> library naming.  However, it can be used for detecting library
> version numbers, and the other way you mention is perfectly valid
> too.  And when it is installed, it is typically installed as a
> symlink to the actual library, which is usually marked by the
> major version of the library released.

I still do not see any meaningful purpose of such symlink. Say you
have libfoo.so.1.2 in a new version of port after libfoo.so.1.1 in
previous. What does it mean? That libfoo.so.1.2 has a different
ABI/API than libfoo.so.1.1? In such case it should be named
libfoo.so.2. That's why I'm saying that such numbering scheme is
broken and does only create confusion and clutter ${PREFIX}/lib.

> > > Removing symlinks for no reason breaks FreeBSD's compatibility
> > > with the rest of the world, which installs them.
> >
> > I strongly disagree. Shared libraries in FreeBSD should be named
> > libfoo.so.X, or at least libfoo-X.Y.so.Z, all other ways should be
> > discouraged and threated as broken, no matter whether the library was
> > installed as a part of the base system or as a part of a port. This
> > contributes to overall OS consistency, which always was a strong
> > selling point of FreeBSD as compared to Linux (for example) and
> > according to my practice usually doesn't create any significant
> > additional overhead or any compatibility problems "with the rest of
> > the world".
> 
> *WHY* are they broken?  What exactly breaks if we install these
> symlinks?  It does create a significant compatibility problem if

See above.

> a user is unable to use FreeBSD as a development platform without
> needing to use ports for everything.

Why? I do not see a single reason for that. He/she will be able to
link with that shared library without any problems using -lfoo,
exactly as on any other architecture out there.

> Furthermore, exactly how
> does removing these symlinks make FreeBSD more consistent?

Repeat after me: libfoo.so.X.Y naming scheme does not serve any
meaningful porpose and therefore was depreciated after switching to
elf.

> FreeBSD shouldn't change the method which upstream vendors use to
> install their libraries, because consistency is not possible
> without breaking with a given two upstreams' chosen path, and
> changing the upstream's choice takes too long to be worth it
> (considering how trivial this is), or may even be impossible.
> Users don't give a flying rat's behind exactly how library names
> are marked with version numbers.  It is only relevant to
> developers IMHO.

See above. We shouldn't just blindly copy vendor's mistakes and
absence of clue.

=Maxim

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D4A6149.1054DFF7>