|
Message-ID: <20140721024834.GM17402@brightrain.aerifal.cx> Date: Sun, 20 Jul 2014 22:48:34 -0400 From: Rich Felker <dalias@...c.org> To: Weldon Goree <weldon@...gurwallah.org> Cc: musl@...ts.openwall.com Subject: Re: Packaging: Slackware On Sat, Jul 19, 2014 at 08:24:12AM +0530, Weldon Goree wrote: > > On 07/19/2014 01:23 AM, Rich Felker wrote: > > > > > If you have thoughts on why you don't want to use 1.1.x, hearing those > > would be helpful in further planning how to proceed with 1.0.x. > > > > The only reason I preferred it was looking at the roadmap and release > history; a slackware version lives for a couple of years generally (with > a point release in the middle) and a build should hopefully be good for > that long. I wanted something that was just getting security updates > during roughly that period. I see. > That said, > 1. Musl doesn't version symbols, so it shouldn't break ABI over that > time (right?) Right. If there's a need to break ABI at some point it will be done with a completely new ldso name or new arch variants if it's just for some archs. > 2. Ultimately slackbuilds just need to be source-compatible with each > other, so even if it breaks ABI over that time it's not a game killer. > (Slackbuilds have some downstreams that distribute binary packages, but > it's explicitly not the project's goal to support that if it comes down > to it.) 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. > And, in fact, what would be a game killer is if 1.0 is going to *stop* > getting security backports over the next year or so, which would mean I > should definitely do the 1.1 branch. I would lean towards using 1.1. It's certainly going to make your life easier if you want to compile software against it since adding features and improving software compat is outside the scope of changes that go into the 1.0.x branch. If there's demand for 1.0.x we could consider keeping up just security fixes for a year or more, but what makes this somewhat difficult is that, for libc, it's really hard to characterize what is a "security" bug. In principle any violation of an interface contract might lead to a vulnerability in an application that's assuming the contract is satisfied. So far I've backported most bug fixes, regardless of severity, as of the date of the 1.0.3 release; IIRC the only ones I didn't backport were for the experimental x32 and sh ports which should not be treated as working in the 1.0.x branch (and I question whether they're even usable now). Rich
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.