Latest thoughts on user level package management

[Nick Coghlan]

On 4 June 2015 at 17:41, Nick Coghlan <ncoghlan at gmail.com> wrote:
> = Aleph 4: Developer components =
>
> Publication format: nix???
> Build system: ????
> Consumption formats: nix???

> = Aleph 5: Upstream components =
>
> Publication format: language dependent
> Build system: ????
> Consumption formats: language dependent

Colin's latest rpm-ostree announcement on atomic-devel highlighted a
very interesting contribution from Alexander Larsson which better
leverages our existing work on improving RPM dependency management:
using kernel-free rpm-ostree builds to define container contents.

Folks can then use OS level containerisation tools like Docker,
systemd-nspawn, xdg-app or linux-user-chroot to separate these
environments from the main system environment. That last one is
particularly important, as it's designed to let you spawn new isolated
environments *without needing root access yourself*:
http://linux.die.net/man/8/linux-user-chroot.

Service containers and other application level update management silos
would be composed via rpm-ostree from Aleph 0-3 components, while
default installations of host platforms would be composed from Aleph
0-1 components.

If we went down that path, then the separation between Alephs 4 & 5
wouldn't be necessary - Aleph 4 would instead become:

=================
= Aleph 4: Upstream ecosystems =

Publication format: ecosystem dependent
Build system: ecosystem dependent
Consumption formats: ecosystem dependent

For upstream software distribution ecosystems, we'd aim to provide
developers with the following:

* tools that allow developers to access that ecosystem (e.g pip for
Python, npm for Node.js, etc)
* tools that allow relatively straightforward conversion of upstream
components to RPM formats

The tools themselves would live somewhere in Alephs 0-3 (depending on the tool)

For ecosystems with tooling that supports redistribution, we'd also
aim to provide a way for folks to collaborate on the preliminary
reviews that check for good faith publication (e.g. checking that the
software isn't obviously malicious) and compliance with Fedora's
licensing policies.
=================

Under that model, the tools that support alternative packaging and
distribution tech like Nix and conda could still be included in Fedora
(or at least Fedora Playground) for developers and data analysts to
use, but they wouldn't become part of the way any of the Fedora
Editions themselves were put together - that would remain the province
of RPM and RPM composition tools like rpm-ostree.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia