Re: Packaging: Slackware

[Rich Felker <dalias@libc.org>]

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