Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20130307160417.86e9d017.idunham@lavabit.com>
Date: Thu, 7 Mar 2013 16:04:17 -0800
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: musl vs. Debian policy

On Thu, 7 Mar 2013 18:56:35 +0000
Justin Cormack <justin@...cialbusservice.com> wrote:

> 
> What is the idea of packaging Musl for Debian? I can see several options
> but none of them seem very plausible. No other package is likely to require
> Musl. A Musl based Debian might be nice but that's a very different
> requirement. Maybe I am missing something.

Mainly the same reason they include klibc, dietlibc, and uclibc-source: a small libc for initrds, small static binaries, and cross-compilation.
mksh, ngetty, and slidentd all refer to use of dietlibc, and klibc is used for initrds. 

musl's policy about maintaining ABI and availability as a shared library may prove advantageous to Debian, also.  

Up till now I've been speaking about reasons a musl package would be useful within a libc6-based distro; but a musl package is necessary for a Debian musl port. A good number of embedded systems start off Debian, Emdebian, or the uclibc port of Debian. The ability to build a Debian system based around musl may aid in adoption of musl, and Debian's attitude towards compatability makes it a good place to start.

I should note that with multiarch, it actually would be possible to use a prepackaged musl for cross-compilation. 

HTH, 
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.