Packaging: Slackware

Packaging: Slackware

[Weldon Goree]

I'm asking on the Slackbuilds list, too, but just to cover all bases:
anybody's toes going to get stepped on if I go forward with a slackbuild
of musl and submit it? I don't intend to touch 1.1.X at all and only
package the latest 1.0.X.

(And, on that note, Rich, what's the support expectation lifetime for
1.0.X, if that's defined?)

Thanks,
Weldon

Re: Packaging: Slackware

[Rich Felker]

On Fri, Jul 18, 2014 at 02:36:42PM +0530, Weldon Goree wrote:
> I'm asking on the Slackbuilds list, too, but just to cover all bases:
> anybody's toes going to get stepped on if I go forward with a slackbuild
> of musl and submit it? I don't intend to touch 1.1.X at all and only
> package the latest 1.0.X.
> 
> (And, on that note, Rich, what's the support expectation lifetime for
> 1.0.X, if that's defined?)

There was a thread about the usefulness and lifetime of the 1.0.x
series about a month ago. The interest level was very low so my plan
based on that was to stick to only important bug fixes, and phase it
out within the next 4-6 months. But to do that, I'm looking for ways
to help distros/users integrate 1.1.x releases without being "forced
to upgrade" earlier than they want to in order to get bugfixes.

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.

Rich

Re: Packaging: Slackware

[Weldon Goree]

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.

That said,
1. Musl doesn't version symbols, so it shouldn't break ABI over that
time (right?)
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.)

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.

Weldon

Re: Packaging: Slackware

[Rich Felker]

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

Re: Packaging: Slackware

[James B]

On Sun, 20 Jul 2014 22:48:34 -0400
Rich Felker <dalias@libc.org> 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 slackbuilds.org which collects thirdparty slackbuilds (ie build recipes that are not part of official Slackware repository) for others to use. Slackbuilds.org 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.

cheers!

-- 
James B <jamesbond3142@gmail.com>

Re: Packaging: Slackware

[Rich Felker]

On Mon, Jul 21, 2014 at 09:04:10PM +0700, James B wrote:
> On Sun, 20 Jul 2014 22:48:34 -0400
> Rich Felker <dalias@libc.org> 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 slackbuilds.org which collects thirdparty
> slackbuilds (ie build recipes that are not part of official
> Slackware repository) for others to use. Slackbuilds.org 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.

Rich

Re: Packaging: Slackware

[Weldon Goree]

On 07/21/2014 07:45 PM, Rich Felker wrote:
> 
> 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,

The intent is to provide a build script that builds a musl environment
that one could then use to build other build scripts in the repository
(James B's description was good). I'm trying to get some anecdata on
what the people who mentioned being interested in a musl build script
want (cross toolchain vs. gcc wrapper with some environment setup vs.
just the library itself).

The point of making a build script in the trivial case is that it
integrates it (in a predictable way) with slackware's package
management/file finding system ("where did I put the cross-x86 version's
files again?", etc.).

Weldon

Re: Packaging: Slackware

[Rich Felker]

On Mon, Jul 21, 2014 at 08:12:58PM +0530, Weldon Goree wrote:
> On 07/21/2014 07:45 PM, Rich Felker wrote:
> > 
> > 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,
> 
> The intent is to provide a build script that builds a musl environment
> that one could then use to build other build scripts in the repository
> (James B's description was good). I'm trying to get some anecdata on
> what the people who mentioned being interested in a musl build script
> want (cross toolchain vs. gcc wrapper with some environment setup vs.
> just the library itself).
> 
> The point of making a build script in the trivial case is that it
> integrates it (in a predictable way) with slackware's package
> management/file finding system ("where did I put the cross-x86 version's
> files again?", etc.).

This sounds good. Given the prevalence of C++ these days (which I'm
rather unhappy about), musl-gcc has limited usefulness; for example
it's hard to even compile a cross-compiler with it, since gcc 4.8+ are
written in C++. So I would lean towards providing a native musl-based
compiler using the patches from musl-cross (these fix some header
issues, default dynamic linker path, libstdc++ build, etc. for working
with musl).

One remaining open item on the wiki is making musl-gcc work with C++
(i.e. sufficient compatibility to use the host libstdc++). I think the
problem here is either that gcc adapts its C++ headers to the host
libc, or just that it's using precompiled headers which pulled in part
of the libc headers. If someone could debug this and find a
workaround, we might be able to revitalize musl-gcc as a serious
development option (and it would make bootstrapping a lot easier).

Rich

Re: Packaging: Slackware

[Rich Felker]

On Mon, Jul 21, 2014 at 08:12:58PM +0530, Weldon Goree wrote:
> On 07/21/2014 07:45 PM, Rich Felker wrote:
> > 
> > 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,
> 
> The intent is to provide a build script that builds a musl environment
> that one could then use to build other build scripts in the repository
> (James B's description was good). I'm trying to get some anecdata on
> what the people who mentioned being interested in a musl build script
> want (cross toolchain vs. gcc wrapper with some environment setup vs.
> just the library itself).
> 
> The point of making a build script in the trivial case is that it
> integrates it (in a predictable way) with slackware's package
> management/file finding system ("where did I put the cross-x86 version's
> files again?", etc.).

Just ran across the slackbuild from a user asking questions about it,
and found one thing that really should be fixed: it's passing
--syslibdir=/usr/lib${LIBDIRSUFFIX} to the configure script. This will
result in dynamic-linked programs built against musl using your
slackbuild working only on slackware systems with the same slackbuild,
and not being portable to other systems. --syslibdir is where the
dynamic linker is found, and it needs to be an invariant for all
systems, and it should be "/lib". The only reason configure allows you
to change it at all is for doing local installations as a non-root
user, and in this case your dynamic-linked binaries won't be portable.

If you fix this, it would be nice for new versions of the package to
keep a symlink to the dynamic linker in the old location, so that old
binaries continue to work while new ones are built with the standard
dynamic linker location and portable to other systems.

Rich