mirror of
https://github.com/NixOS/rfcs.git
synced 2025-11-08 19:46:12 +01:00
[RFC 0023] Support musl libc (#23)
* copy rfc template, unnumbered as of yet * musl-libc RFC: first draft * musl-libc RFC: rename to patch pull req number * musl-libc: whoops, no links in top bit, that's metadata. Move links to later. * record the name of a brave co-author * musl rfc: squash second batch of changes * rfc: specify initial team \o/, add a small clarification. * Add myself to the "musl team"
This commit is contained in:
Will Dietz
Eelco Dolstra
parent
5d91defc4d
commit
13b5084807
1 changed files with 334 additions and 0 deletions
334
rfcs/0023-musl-libc.md
Normal file
334
rfcs/0023-musl-libc.md
Normal file
|
|
@ -0,0 +1,334 @@
|
|||
---
|
||||
feature: musl-libc
|
||||
start-date: 2018-02-19
|
||||
author: Will Dietz (@dtzWill)
|
||||
co-authors: Shea Levy (@shlevy)
|
||||
related-issues: 34645, 6221, ...
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Summary
|
||||
[summary]: #summary
|
||||
|
||||
When targeting Linux platforms, Nixpkgs builds software against
|
||||
the defacto standard of Linux libc implementations:
|
||||
[glibc](https://www.gnu.org/software/libc/).
|
||||
|
||||
This RFC proposes adding **experimental** support in Nixpkgs for the use
|
||||
of an alternative libc implementation, [musl](https://www.musl-libc.org/),
|
||||
for the reasons outlined below.
|
||||
Adding this support is similar to introducing support for an architecture,
|
||||
and realistically will be limited in compatibility and features
|
||||
compared to non-musl siblings such as `x86_64-unknown-linux-gnu`.
|
||||
|
||||
Initial support is already available in nixpkgs master, capable
|
||||
of building up through important packages such as nixUnstable itself
|
||||
and LLVM. This is not to be taken as an endorsement: discussing
|
||||
and ultimately deciding whether support for musl should be part of nixpkgs
|
||||
is the subject of this RFC. That said, this initial support is
|
||||
a reasonable foundation for evaluating technical details discussed below,
|
||||
and a convenient way for interested parties to explore the work so far.
|
||||
|
||||
To help ensure we're all on the same page, unless otherwise specified
|
||||
assume references to musl support implementation are in reference
|
||||
to this commit (latest master at time of writing):
|
||||
|
||||
[bd7d5b365799a145717d31122ebfd24b51fea117](https://github.com/NixOS/nixpkgs/commit/bd7d5b365799a145717d31122ebfd24b51fea117)
|
||||
|
||||
# Motivation
|
||||
[motivation]: #motivation
|
||||
|
||||
## Why Musl?
|
||||
There are many reasons to prefer the use of musl.
|
||||
|
||||
musl is advertised as being:
|
||||
* lightweight
|
||||
* fast
|
||||
* simple
|
||||
* free
|
||||
* correctness: standards-conforming
|
||||
* correctness: safety
|
||||
|
||||
Additionally it is very popular when statically linking software,
|
||||
creating binaries capable of executing most anywhere.
|
||||
|
||||
In fact it is for this reason that Nixpkgs itself builds
|
||||
the bootstrap busybox using musl.
|
||||
|
||||
A somewhat outdated overview comparing musl against other
|
||||
implementations is available [here](http://www.etalabs.net/compare_libcs.html).
|
||||
Note this comparison is maintained by the (primary) author of musl,
|
||||
(as indicated at the top of the page).
|
||||
|
||||
I'm unable to find good numbers but musl is "arguably" the second
|
||||
most popular libc implementation on Linux, and is used
|
||||
by a number of important projects you may be familiar with
|
||||
large userbases, including:
|
||||
* Alpine Linux - [#70 on Distrowatch](https://distrowatch.com/table.php?distribution=alpine) but very popular amongst docker users for producing slim container images.
|
||||
* [OpenWRT/LEDE](https://openwrt.org/) - #1 open-source Linux router firmware project; foundation of most other projects targetting routers.
|
||||
More projects and details of how they use musl can be found here:
|
||||
|
||||
https://wiki.musl-libc.org/projects-using-musl.html
|
||||
|
||||
## Why Nixpkgs?
|
||||
|
||||
The importance of musl is not the primary point of contention in this RFC,
|
||||
instead perhaps the main question is whether such support belongs in Nixpkgs or not.
|
||||
|
||||
The main arguments for inclusion are:
|
||||
* **convenience of use**
|
||||
* **foundation for exciting future work**: musl is widely used by high-level languages
|
||||
as the libc implementation used to produce statically linked programs:
|
||||
these are easy to deploy, launch quickly, and only include the code required.
|
||||
(NOTE: currently musl support prefers dynamic linking and shared libraries
|
||||
as is the strong preference in Nixpkgs)
|
||||
* Software sometimes must be patched to compile or run with musl; in @dtzWill's experience,
|
||||
these changes are largely fixes improving compliance and correctness resulting in
|
||||
higher-quality programs. Recent versions of glibc have started taking stronger stances
|
||||
on enforcing compliance (look at patch fallout folllowing any glibc upgrade in last year or so)
|
||||
resulting in overlapping work from both sides.
|
||||
(NOTE: use of glibc extensions or reliance on non-standard behavior is still common and unlikely to go away soon)
|
||||
|
||||
And to a large extent:
|
||||
"Why not?" -- similar to including support for architectures such as Aarch64 or RISC-V,
|
||||
and just like support for those architectures it's relatively clear that pushing them
|
||||
into private forks would be detrimental to the nixpkgs project as well as all users
|
||||
interested in using Nixpkgs on those platforms/architectures.
|
||||
|
||||
musl is clearly useful for a variety of important use cases,
|
||||
however including support has a few costs (see Drawbacks, below):
|
||||
do folks believe the costs are too high?
|
||||
|
||||
|
||||
## Additional Resources
|
||||
|
||||
* [musl FAQ](https://www.musl-libc.org/faq.html)
|
||||
* [projects using musl](https://wiki.musl-libc.org/projects-using-musl.html)
|
||||
* [Slides from a talk discussing various libcs, 2014](http://events17.linuxfoundation.org/sites/events/files/slides/libc-talk.pdf)
|
||||
|
||||
## Related Isssues
|
||||
|
||||
* [big musl PR](https://github.com/NixOS/nixpkgs/pull/34645)
|
||||
* [issues matching "musl", newest first](https://github.com/NixOS/nixpkgs/search?o=desc&q=musl&s=created&type=Issues&utf8=%E2%9C%93)
|
||||
* [2015 libc discussion](https://github.com/NixOS/nixpkgs/issues/6221#issuecomment-116754223)
|
||||
|
||||
# Detailed design
|
||||
[design]: #detailed-design
|
||||
|
||||
## Goals
|
||||
### Laying the Foundation
|
||||
|
||||
Implement the following in nixpkgs:
|
||||
|
||||
* [x] musl-based bootstrap
|
||||
* [x] stdenv for native musl building
|
||||
* [x] cross-musl stdenv
|
||||
|
||||
These are already implemented and are currently tested
|
||||
to build and provide basic functionality as part
|
||||
of release-cross.nix.
|
||||
|
||||
These features would be very difficult to implement
|
||||
or maintain externally, and near impossible as an overlay.
|
||||
|
||||
## Package Compatibility
|
||||
|
||||
For a variety of reasons many packages do not work out-of-the-box
|
||||
in musl-based environments.
|
||||
|
||||
### "Normalization"
|
||||
|
||||
Vast majority of the problems here are "minor" and are the
|
||||
sort of problem we regularly encounter and address when
|
||||
bumping to a new glibc version, new gcc version, or using
|
||||
a clang-based stdenv (such as on Darwin).
|
||||
|
||||
I'm calling these fixes "normalization".
|
||||
These are changes like "adding a missing include" or
|
||||
"don't assume compiler is invoked 'gcc'".
|
||||
|
||||
These changes usually can be safely applied on all platforms
|
||||
(although sometimes they are not for rebuild reasons)
|
||||
and are easy to check for correctness or at least "couldn't-possibly-hurt".
|
||||
|
||||
### Big Incompatibilities
|
||||
|
||||
Some packages are very much not portable and require significant
|
||||
and invasive changes to work with environments they don't expect.
|
||||
|
||||
In the context of this RFC's proposed musl support,
|
||||
there are a number of packages that are known to be in this category:
|
||||
|
||||
* systemd
|
||||
* ...
|
||||
|
||||
This RFC proposes ignoring those for the immediate future,
|
||||
to be revisited later, and focuses on systemd.
|
||||
|
||||
#### Systemd
|
||||
|
||||
Currently many packages depend on systemd.
|
||||
This dependency is indirect for all but a handful of packages,
|
||||
with a few key pieces of software integrating with systemd.
|
||||
|
||||
As far as I know this dependency is generally optional,
|
||||
and so we could easily avoid its use when using musl.
|
||||
|
||||
This makes it possible to build a great number of packages
|
||||
(thousands) but more complicated software "ecosystems"
|
||||
and "desktop environments" will not work without something
|
||||
to tie them together with the various roles played by systemd.
|
||||
|
||||
Addressing this in any way is not in the scope of this RFC.
|
||||
|
||||
Similarly, NixOS itself (especially services) require systemd
|
||||
and we do not propose altering this.
|
||||
|
||||
An early version of the "musl PR" patched systemd so that it
|
||||
would build successfully, using patches from OpenEmbedded.org.
|
||||
|
||||
The result was never tested or reviewed in terms of providing
|
||||
basic functionality or general suitability for Nixpkgs/NixOs.
|
||||
|
||||
(OE folks do great work, but they may expect rather different
|
||||
things from systemd or workaround introduced shortcomings elsewhere
|
||||
in various capacities)
|
||||
|
||||
## Scope
|
||||
|
||||
Primarily non-GUI packages for now, due to systemd blocker.
|
||||
|
||||
In the future these will be supported.
|
||||
|
||||
This RFC is primarily concerned with the groundwork for using musl at all.
|
||||
|
||||
## Testing and Maintenance
|
||||
|
||||
"Ideally" the answer would be an infinite number of builders would constantly
|
||||
build all the things on all the platforms.
|
||||
|
||||
Unfortunately this is unrealistic due to capacity constraints and other reasons.
|
||||
|
||||
### Responsibility
|
||||
|
||||
"musl team" is reponsible, initially consisting of
|
||||
|
||||
* @dtzWill
|
||||
* @shlevy
|
||||
* @domenkozar
|
||||
* @rasendubi
|
||||
|
||||
A team handle will be created to track this
|
||||
and to ping the team on musl-related discussion or issues.
|
||||
|
||||
### Infrastructure
|
||||
|
||||
Build at least stdenv with more being added in the future.
|
||||
|
||||
Jobs may be given lower priority/shares.
|
||||
|
||||
# Drawbacks
|
||||
[drawbacks]: #drawbacks
|
||||
|
||||
Why should we *not* do this?
|
||||
|
||||
Potential maintenance burden, particularly regarding collections of patches,
|
||||
seems to be the primary concern.
|
||||
|
||||
## Additional Costs
|
||||
|
||||
* Maintenance
|
||||
* Infrastructure (build pressure, storage, ...)
|
||||
|
||||
## Fractured Community
|
||||
|
||||
> Another issue: adding musl support fractures the Nixpkgs user/development community: some people will run musl-based packages and some will run glibc-based packages. As a result all of Nixpkgs/NixOS will end up being less tested. it doubles the test matrix on Linux, after all.
|
||||
|
||||
## Previous Discussion of drawbacks and concerns
|
||||
|
||||
This RFC was prompted by concerns about the drawbacks:
|
||||
["I'm really not in favour of adding support to Nixpkgs"](https://github.com/NixOS/nixpkgs/pull/34645#issuecomment-366789321).
|
||||
This comment echoes very similar concerns expressed [back in 2015](https://github.com/NixOS/nixpkgs/issues/6221#issuecomment-116754223).
|
||||
|
||||
# Alternatives
|
||||
[alternatives]: #alternatives
|
||||
|
||||
* Maintain in a separate fork
|
||||
* [SLNOS project is willing to adopt](https://github.com/NixOS/nixpkgs/pull/34645#issuecomment-366845015)
|
||||
* Maintained as an overlay
|
||||
* No musl libc support.
|
||||
* Not really an "alternative" :).
|
||||
|
||||
# Unresolved questions
|
||||
[unresolved]: #unresolved-questions
|
||||
|
||||
What parts of the design are still TBD or unknowns?
|
||||
|
||||
## Support
|
||||
|
||||
We need to work on defining:
|
||||
|
||||
* What "Support" entails
|
||||
* Responsibility
|
||||
* Blame?
|
||||
|
||||
For now we leave it as an informal understanding
|
||||
which we can improve on in the future.
|
||||
|
||||
## Impact
|
||||
|
||||
### Infrastructure
|
||||
|
||||
* Hydra
|
||||
* ofborg
|
||||
|
||||
### Complexity
|
||||
|
||||
* evaluation complexity
|
||||
* cost of behind-the-scenes "magic" required
|
||||
* keeping expressions avoidable
|
||||
* cyclomatic complexity
|
||||
|
||||
## How to Remove?
|
||||
|
||||
Is there a good way to move forward
|
||||
without becoming impossibly intertwined?
|
||||
Such that a future party could
|
||||
* reduce nixpkgs to what it "would be" without musl support
|
||||
* Do so confidently without worrying about subtle
|
||||
breakages?
|
||||
|
||||
Maintaining entirely as an overlay (or fork?)
|
||||
is an obviously effective solution in this regard.
|
||||
Clear separation and enforced use of carefully crafted
|
||||
interfaces/abstractions may also help with this.
|
||||
|
||||
To some extent the importance of this depends
|
||||
on how likely the community expects to find itself
|
||||
"regretting" or wanting to be "rid" of musl support.
|
||||
|
||||
However the design and use of good abstractions
|
||||
is valuable in all cases :).
|
||||
|
||||
# Future work
|
||||
[future]: #future-work
|
||||
|
||||
### Fetch, Unpack, Patch
|
||||
|
||||
(TODO: Split to new RFC?)
|
||||
It may be possible to leverage proper use of "phases" so that
|
||||
we can provide reasonable coverage of the unpack and patch
|
||||
phases for all "supported" configurations.
|
||||
|
||||
As an example, this would make it possible for our x86_64 builders and users to
|
||||
get feedback ensuring that changes didn't break hashes or patch application
|
||||
elsewhere without requiring builders of each configuration.
|
||||
|
||||
The benefit of this would be in avoiding most of the burden of building everything
|
||||
while making it easy to catch the most common sort of problems
|
||||
so they can be addressed ("oops I didn't update the hash for darwin")
|
||||
or flagged for investigation.
|
||||
|
||||
I believe there's a branch or PR trying this somewhere.
|
||||
Regardless, out of scope for this RFC.
|
||||
Loading…
Add table
Add a link
Reference in a new issue