[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130307170326.c8530e4b.idunham@lavabit.com>
Date: Thu, 7 Mar 2013 17:03:26 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: musl vs. Debian policy
On Thu, 7 Mar 2013 08:04:24 -0500
Rich Felker <dalias@...ifal.cx> wrote:
> > I started writing a short explanation of the musl installation for packagers, and realized that there's one area that's inconvenient:
> > $syslib/ld-musl-*.so.1 is a symlink to libc.so.
> >
> > Debian policy requires that any public libraries have a version number.
> > Specifically, Debian Policy 8.2
> > (http://www.debian.org/doc/debian-policy/ch-sharedlibs.html):
> > If your package contains files whose names do not change with each
> > change in the library shared object version, you must not put them
> > in the shared library package. Otherwise, several versions of the
> > shared library cannot be installed at the same time without filename
> > clashes, making upgrades and transitions unnecessarily difficult.
>
> Are you sure this applies? I don't think the libc.so in musl counts as
> a "public library" as nothing references it by name. Moreover, if
> installing as a package on a glibc-based distro, it should not be
> installed in /usr/lib (where it would clash with glibc's libc.so
> linker script) but rather its own path.
Public library==any library other than a "convenience library" (a library that is included in a binary package such as xorg-xserver-core, and is not intended to be linked against except programs in the binary package itself).
What the policy is saying is that if you have a shared library
package (for our example, musl1), it cannot have any file that
doesn't change names if you have to break ABI compatability.
The reason the Debian policy gives is that this ensures that
if we do end up breaking ABI compatability (such as when fixing
incorrect types or revising pthreads), the musl2 package that will
be needed can be installed on the same system as musl1, thus
allowing people to keep using musl1-linked programs until updates
are available.
I know it's our policy to maintain a stable ABI, but I doubt that we can guarantee that there will NEVER be an abi breakage. Not wanting to do something is a bad reason for acting like it won't happen.
> > The apparent solution to this is to ship only the dynamic linker,
> > since this is all we need (the dependency on libc.so is disregarded
> > when it comes to running dynamically linked programs). But
> > currently, actually doing this would be somewhat of a hack.
> >
> > Is there any prospect of installing lib/libc.so straight to
> > ${LDSO_PATHNAME} ? I'm thinking it could be done via something like:
>
> This has been proposed before, and the main obstacle was build-system
> difficulties if I remember right. I'd still like to consider doing it,
> but it would be nice to be able to do it for its own sake rather than
> for the sake of satisfying distro policy being applied where it
> doesn't make sense. Maybe we can try to figure out Debian's stance
> before we rush into making the change for their sake.
I'm actually more interested in it for the reasons Debian gives (explained above) than "because Debian says that's how to do it."
Of course, the possibe side-effects if Debian packagers were to go
about it their own way and ended up with a different linker name are also rather obnoxious. I realize that's not a very pressing issue,
since there isn't an RFP or ITP yet.
But my main point is to ask whether, if I prepare a patch that
does the job, it would be welcome.
--
Isaac Dunham <idunham@...abit.com>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
