On 23 March 2015 at 19:48, Antti Kantee <[email protected]> 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 ;) > > Given mato's experiments in making it possible to "rumprun" unmodified > software packages, we are starting to face a problem common in OS-land: how > to make it easy to use 3rd party software without having to compile > everything manually and track library dependencies by hand. The current > "quick and easy way to provide something usable" by managing rumprun > packages as separate github repositories will not scale either from a > maintenance or usability perspective. > > 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. > > A packaging system could also push app-tools to be an expert-level > interface, while the packaging system would be the one for which the user > experience is optimized. That said, I'm not sure if it matters. > > A related but not-immediately-relevant subproblem is how would you create a > rumprunnable image with multiple "executables". I think it's safe to start > with one executable being the goal and figure out the next step after that > goal has been reached. We just need to make sure multiexecutable mode is at > least theoretically possible with the hooks offered by the packaging system. > > 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 > > 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. > > Thoughts?
I think it might help to divide it into two problems: 1. I want to build piece of software x for rumprun. It needs a bunch of libraries which are not included, so I need to build them, and have a nice way to do updates when openssl has a security hole. 2. I want to distribute a bunch of prebuilt software (with config files potentially) for people to install. At this point there are no dependency management issues, but there are other things eg signing, other metadata. For 2, I was wondering about the Rocket App Container spec https://github.com/appc/spec/blob/master/SPEC.md - it is essentially signed tarfiles and a metadata spec. Obviously there are some constraints (only one executable in the package), but it is mostly applicable. Justin
