On Monday, 23.03.2015 at 19:48, Antti Kantee wrote:
> Hi,
>
> This post is very handwavy just to put the subject on the radar. If
> you're not interested in handwaving, better not read further ;)
Handwavy reply coming up :-)
> Much like a regular packaging system, the rumprun packaging system
> would offer a repository of prebuild software, and especially in the
> beginning an easy way to create such a repository locally. This
> software would of course be entirely cross-compiled, as is possible
> with some packaging systems. The software would also be
> "cross-installed" into a rumprunnable image with no support for
> altering the package configuration. If you want to upgrade packages
> or change the configuration, you rebuild the image and re-run it.
> Yes, it would be possible to work in some sort of
> poke-the-binary-and-live-upgrade-the-kernel nonsense, but let's aim
> for the simplest solution, not the most complex one.
At least for Xen and the four pieces of software I've packaged on an
ad-hoc basis so far (mathopd, nginx, php, MySQL) the configuration and data
are currently kept separate from the kernel binary.
At build time my ad-hoc packaging generates an ISO or FFS filesystem image
(or images) which are then provided to the rump kernel as Xen block devices.
This is an implementation detail; they could be provided as network
("host") filesystem mountpoints, network block devices, cloud storage
(think EBS/S3), baked into the kernel blob, or even bootloader environment
(for bare metal/embedded) or any combination of these.
I'm not yet convinced that baking configuration (or any other data) into
the resulting binary is in the initial scope of what the *packaging* system
should be doing. This may be a case for a separate "rumpbake" tool, once we
understand the problem space better.
> So, summarizing the requirements of the packaging system:
>
> 1) established set of packages
> 2) cross-compile support
> 3) easy to build your local binary repositories from a *subset* of
> the supported packages
> 4) cross-installation support, i.e. create image from {x} packages
> 5) at least theoretical viability for some crunchgen-like
> multiexecutable mode
6) it should be easy for users to create their own public package
repositories, something akin to an Ubuntu PPA (Personal package archive).
This is a really easy way for the community to get involved in packaging
software they're interested in.
7) *if* possible, the process of updating a rumprun package when
upstream releases a new (stable/API-compatible) version should be as
maintenance-free (automated) as possible. I'd like to avoid getting into a
situation where a maintainer has to do manual steps whenever OpenSSL
1.0.3.1.4.1.5.9axz comes out.
One more thing to note -- as I see it, there are two kinds of packages:
a) Components, ie. libraries that an application depends on. Think OpenSSL,
libcurl, MySQL client library, $RANDOM_PHP_EXTENSION, etc. Building a
component does not result in a kernel image, only in libraries and header
files being installed in some yet-to-be-determined place where the
packaging system and toolchain can see them.
b) Applications, which may depend on some subset of components, and the
result of a build is a kernel image (or some pseudo-image for later
linking/baking).
I don't know yet how important this distinction is. If we can work out a
way of doing pseudo-linking (Antti?) to introduce a final "bake" step then
its possible that it might be less relevant.
> Does anyone know which existing packaging system would best suit the
> goal? I think pkgsrc and xbps are at least seemingly viable
> candidates, but as always, it's the details which matter.
I've heard good things about Nix (https://nixos.org/nix/), but have no idea
if it is applicable to our use-case.
-mato
