Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 21 Jul 2014 10:15:25 -0400
From: Rich Felker <>
To: Weldon Goree <>
Subject: Re: Packaging: Slackware

On Mon, Jul 21, 2014 at 09:04:10PM +0700, James B wrote:
> On Sun, 20 Jul 2014 22:48:34 -0400
> Rich Felker <> wrote:
> > 
> > Knowing a little bit more about the goal of the slackbuild (and what
> > exactly a "slackbuild" is) might help me make a better recommendation
> > and assess whether extending the life of the 1.0.x branch is
> > worthwhile for what you're doing.
> "Slackbuild" is a build recipe, just like RPM spec file or Arch PKGBUILD.
> There is a website called which collects thirdparty
> slackbuilds (ie build recipes that are not part of official
> Slackware repository) for others to use. tend to
> group slackbuilds following Slackware official releases (there is a
> group of slackbuilds targetted for Slackware 13, Slack 14, Slack
> 14.1, etc etc).
> I'm not speaking on behalf of Weldon but I guess this would be where
> the musl slackbuild will end up.

Yes. I'm still not clear though on whether the intent is to provide an
environment for musl-[dynamic-]linked programs running on Slackware,
or more for a development environment using the musl-gcc wrapper. This
might affect the stability requirements. Of course if it's just a
development environment using the wrapper, there may not be a lot of
point in packaging that since you already need a compiler to use it,
and with a compiler you can build musl (whichever version you want) in
a matter of seconds on a modern workstation.


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.