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/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
