On 09/04/15 11:48, Martin Lucina wrote:
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.
I probably(*) meant "package configuration" = "set of packages in the
image", not "configuration files for software in the image". My text
was poorly written, so apologies that you had to write a well
thought-out rebuttal for a non-proposal :/
*) I don't honestly remember, but requiring a separate package per
software configuration tweak seems a bit unreal even for me.
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.
Yea, I don't quite know yet. Maybe you can also just point "rumprun" at
a directory and say where it should appear on the guest and whatever
happens after that is an implementation detail which we can vary from
platform to platform and environment to environment.
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.
Good idea.
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.
This, I think, is the main reason for having a packaging system!
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.
Can't the components just be built like they normally are: as libraries?
I don't see them being different from the rump kernel, which is just
libraries too.
The more challenging bit is figuring out how to get more than one "b"
into the image and especially how to control what is going to happen
when you run the image. This is #5 in my list above.
