Packaging divisions

Discussion of the System pitch as well as pondering over my latest endeavors raises the question: while Swift is distributed officially as a large binary package with the standard library, compiler, all libraries with all the tooling trimmings, this may not be an idiomatic means of distributions on other platforms, so where do the dividing lines lie?

One might expect to have a libraries package distinct from the compiler, so that someone interested in a Swift application can install the libraries but not the compiler, but a Swift developer might expect the toolchain to have Testing (or System) without having to explicitly install it.

I know this discussion has happened before. Were any conclusions reached? Does this actually matter, or should platform packagers just use best judgement on this?

1 Like

Good question - splitting the libraries and compiler seems more flexible for different users.
In the end, it probably comes down to platform requirements and packagers using common sense.

There is no official recommendation to my knowledge but this was extensively discussed by the official Debian/Ubuntu packager, @SteveM, on a GitHub issue: you could probably mostly follow his lead with the Ubuntu packages he created, further elaborating as needed.

You could also look at the division I've been using for years with Android in the Termux app, in particular the subpackages that split off files from the standard install.