Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote: Package: wnpp Severity: wishlist Owner: Anibal Monsalve Salazar ani...@debian.org * Package name: libposix Why? 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? -- 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 Developerhttp://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
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 11:03:41AM +0100, Steve Langasek wrote: On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote: * Package name: libposix Why? 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. Once libposix reaches maturity, I will certainly consider linking applications I wrote myself against libposix. Applications linked against it will probably use less memory and cannot inadvertently use glibc extensions. This will make it easier to port those applications, and will also make it easier to run things on embedded platforms. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 6:28 AM, Guus Sliepeng...@debian.org wrote: On Wed, Jun 24, 2009 at 11:03:41AM +0100, Steve Langasek wrote: On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote: * Package name : libposix Why? 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. Once libposix reaches maturity, I will certainly consider linking applications I wrote myself against libposix. Applications linked against it will probably use less memory and cannot inadvertently use glibc extensions. This will make it easier to port those applications, and will also make it easier to run things on embedded platforms. Is libposix complete enough to link against for real programs yet? If not, why should it be included at this time? Moreover, can libposix and libc coexist in the same address space? If not, all of debian's existing libraries will be incompatible with it. It seems like the sort of thing that you might want to build an entire distro against, or a custom/development build against, but not just some programs in a distro... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote: Is libposix complete enough to link against for real programs yet? If not, why should it be included at this time? I agree that if the only thing that works at this moment is the simplest Hello world program, that it should not be packaged yet. 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. But applications can only link against one of them at the time of course. If not, all of debian's existing libraries will be incompatible with it. It seems like the sort of thing that you might want to build an entire distro against, or a custom/development build against, but not just some programs in a distro... 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. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 9:34 AM, Guus Sliepeng...@debian.org wrote: On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote: Is libposix complete enough to link against for real programs yet? If not, why should it be included at this time? I agree that if the only thing that works at this moment is the simplest Hello world program, that it should not be packaged yet. 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. But applications can only link against one of them at the time of course. I mean, if a program is using libposix, can it also link, for example, libpng, which is built against the normal libc? If libposix uses the brk() area for malloc this isn't possible, but if it uses anonymous mmaps exclusively then it might be doable (of course, one would need to be careful to free with the correct malloc implementation). If not, all of debian's existing libraries will be incompatible with it. It seems like the sort of thing that you might want to build an entire distro against, or a custom/development build against, but not just some programs in a distro... 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. For embedded environments, one will generally want a cross-compiling toolchain, not just a library. You can't use the libc headers in /usr/include, or libc's crt*.o start routines, after all, and even uclibc abandoned the approach of hacking a host toolchain into using its libraries. And for an embedded environment, a lot of the time you'll have a different architecture on the target than the host anyway. This is all moot if libposix is still too incomplete to be usable of course :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
Guus Sliepen writes: 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. But applications can only link against one of them at the time of course. I suspect the concern here is dynamically linked libraries. Suppose myapp is linked against libposix (for whatever reason). Suppose libfoo.so is linked against glibc (for whatever different reason). Finally, suppose that myapp links against libfoo.so. When this happens, what breaks, how badly, and how obviously? Michael Poole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
Guus Sliepen g...@debian.org (24/06/2009): On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote: Is libposix complete enough to link against for real programs yet? If not, why should it be included at this time? I agree that if the only thing that works at this moment is the simplest Hello world program, that it should not be packaged yet. Looking at the latest news I could find on the website[1]: | Multiplatform support for libposix | | Posted by hdante on June 6, 2009 | | I'm happy to announce that libposix is able to run Hello World in | three different platforms: linux x86, linux x86_64 and FreeBSD x86. 1. http://libposix.sourceforge.net/ I guess you have your answer. (Don't Cc me if you keep d-d@ in the loop, thanks already.) Mraw, KiBi. signature.asc Description: Digital signature
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 Developerhttp://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
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote: 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? Since they don't link against a large library. Granted, that is only a benefit if all running programs link against libposix instead of glibc. and cannot inadvertently use glibc extensions. So instead you get to reimplement all the extensions you need, in the name of portability? Yes, if that is what it takes for my application to work on platforms that do not have glibc. 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. If I'm compiling I'd rather do it on a fast desktop with all my usual stuff installed than on an embedded system. 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? Although I disagree with your other reasons for not including this library in Debian, I agree that it shouldn't be packaged yet since it is quite unusable in this stage :) -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 6:24 PM, Guus Sliepeng...@debian.org wrote: On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote: 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? Since they don't link against a large library. Granted, that is only a benefit if all running programs link against libposix instead of glibc. What makes you think libposix will be smaller? It is currently very incomplete; by the time it reaches a full implementation of POSIX, it may well be the same size as libc. 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. If I'm compiling I'd rather do it on a fast desktop with all my usual stuff installed than on an embedded system. Again, this is what a cross-compile toolchain is for (mandatory if your embedded platform is anything other than your desktop arch!). You could adapt the crosstool buildscripts that uclibc uses, for example. If you just use debian's normal GCC, you're going to have a hell of a time convincing it to not use libc's include files/statically-linked startup objects/dynamic linker. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Thu, Jun 25, 2009 at 12:24:40AM +0200, Guus Sliepen wrote: On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote: 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? Since they don't link against a large library. Which is a ridiculous argument given what the S in .so means. As soon as at least one always running program on your system uses glibc, you want to only use glibc if you want to save memory. It's simple as that. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 06:33:44PM -0400, Bryan Donlan wrote: Why would they use less memory? Since they don't link against a large library. Granted, that is only a benefit if all running programs link against libposix instead of glibc. What makes you think libposix will be smaller? It is currently very incomplete; by the time it reaches a full implementation of POSIX, it may well be the same size as libc. Glibc implements much more than just POSIX, and it is not known for its leanness, hence the existence of dietlibc, uClibc, etc. If I'm compiling I'd rather do it on a fast desktop with all my usual stuff installed than on an embedded system. Again, this is what a cross-compile toolchain is for (mandatory if your embedded platform is anything other than your desktop arch!). You could adapt the crosstool buildscripts that uclibc uses, for example. If you just use debian's normal GCC, you're going to have a hell of a time convincing it to not use libc's include files/statically-linked startup objects/dynamic linker. That's true. Probably something the upstream maintainer should consider to provide. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Thu, Jun 25, 2009 at 12:41:43AM +0200, Pierre Habouzit wrote: On Thu, Jun 25, 2009 at 12:24:40AM +0200, Guus Sliepen wrote: On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote: 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? Since they don't link against a large library. Which is a ridiculous argument given what the S in .so means. As soon as at least one always running program on your system uses glibc, you want to only use glibc if you want to save memory. It's simple as that. PS: I read the full mail, and the postulate that all Debian can link against libposix is wrong to begin with, because too many GNU stuff heavily relies on GNU extensions to the libc. That's exactly why kFreeBSD uses a GNU libc instead of the BSD one -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Thu, Jun 25, 2009 at 12:54:35AM +0200, Guus Sliepen wrote: On Wed, Jun 24, 2009 at 06:33:44PM -0400, Bryan Donlan wrote: Why would they use less memory? Since they don't link against a large library. Granted, that is only a benefit if all running programs link against libposix instead of glibc. What makes you think libposix will be smaller? It is currently very incomplete; by the time it reaches a full implementation of POSIX, it may well be the same size as libc. Glibc implements much more than just POSIX, and it is not known for its leanness, hence the existence of dietlibc, uClibc, etc. Most of its fat comes from stuff like Sun RPC, or gconv, that thanks to eglibc you can switch off. I'm not saying libposix is a stupid idea, just that it's meaningless to package it in Debian (especially in its current state, but that's _really_ orthogonal). -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
Pierre Habouzit, le Thu 25 Jun 2009 00:41:43 +0200, a écrit : Why would they use less memory? Since they don't link against a large library. Which is a ridiculous argument given what the S in .so means. And linking against a 100MB library will generally _not_ eat 100MB memory during execution. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
Package: wnpp Severity: wishlist Owner: Anibal Monsalve Salazar ani...@debian.org * Package name: libposix Version : 0 Upstream Author : Henrique Almeida hda...@gmail.com * URL : http://libposix.sourceforge.net/ * License : See below Programming Lang: C Description : unifed implementation of core functionality of all Unix systems Licence Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
