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
