Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 12:28:24PM +0200, Guus Sliepen wrote:
> > This is a subset of the interfaces provided by glibc, which must be present
> > on all systems. So it would be stupid for any package in Debian to link
> > against libposix instead of just using libc. Why do we want a library in
> > Debian that no packages should depend on?
> Just see it as dash vs. bash.
I *don't* see it as this, because I can't see any way that libposix will
ever be useful to have used by other Debian packages. dash is useful to
have as the *default* /bin/sh on Debian systems; libposix would not be
useful to have by default.
> Once libposix reaches maturity, I will certainly consider linking
> applications I wrote myself against libposix. Applications linked against
> it will probably use less memory
Why would they use less memory?
> and cannot inadvertently use glibc extensions.
So instead you get to reimplement all the extensions you need, in the name
of "portability"?
> and will also make it easier to run things on embedded platforms.
Why does this make anything easier? If you're rebuilding your whole system
against libposix, you're not doing that in the archive, so packaging
libposix seems largely irrelevant to this; if you aren't rebuilding your
whole system against libposix, you get two libcs, so that's hardly a win for
embedded systems.
On Wed, Jun 24, 2009 at 03:34:32PM +0200, Guus Sliepen wrote:
> > Moreover, can libposix and libc coexist in the same address space?
> What address space are you talking about? There is also dietlibc and
> uClibc, who can coexist with glibc.
uclibc doesn't appear to be packaged.
dietlibc is packaged - in a manner that appears to violate pretty much all
the principles of Policy 8.1 and shared library best practices in general.
(No distinguishing soname distinct from the .so used at build time, to allow
for ABI changes; one of the libs is installed executable (why? it's libdl,
ok, but is that actually used as the dynamic linker for dietlibc-linked
executables?); the libs are installed under /usr/lib/diet/lib, which seems
to imply use of rpath.)
I'm skeptical of the utility of such a level of coexistence.
> Having a glibc replacement for just a few programs is not an argument in itself
> for not including this package. Perhaps I want to develop a program that needs
> to run in an embedded environment that I want to test? Then I'd like to have a
> libposix-dev package that I can use to build my own software with.
If there are to be embedded environments that will use libposix, then that's
an argument for packaging it - but since these environments don't exist
today, it seems premature to me to put the package in Debian. Are there any
use cases for this that are both non-theoretical and non-crackful?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: