Re: rump-mathopd and rump-nginx packages moved, packaging infrastructure

  • From: Martin Lucina <martin@xxxxxxxxxx>
  • To: rumpkernel-users@xxxxxxxxxxxxx
  • Date: Thu, 2 Jul 2015 22:13:53 +0200

On Thursday, 02.07.2015 at 13:05, Antti Kantee wrote:

On 01/07/15 20:16, Antti Kantee wrote:
It'd be good if the other packages in rumprun-packages-wip could make use
of this infrastructure to build rather than having a list of manual

Good idea. I'll convert mpg123. I secretly hope that Krishna will
convert python as part of his "python-static" work ;)

Ok, did that, 'twas simple enough.


I guess we could also do with a, a lot of make targets
seem the same for every package. Not that I want this stopgap
packaging system to turn into a reimplementation of pkgsrc, but
anyway ;)

I agree, however I'm not too hung up on using make. The common boilerplate
consists of mostly a sequential set of "fetch upstream", "maybe patch",
"maybe configure", "build", "install", "maybe make images" steps.

I was thinking that we could build a small DSL for packaging using shell
scripts. Imagine a that looked something like this:

. ../scripts/

package nginx
patches patches/*
configure ./configure ${NGINX_CONF_OPTS}
build make
install objs/nginx nginx.bin
iso_image stubetc.iso ../stubetc/etc
iso_image data.iso images/data

This should be pretty trivial to write, probably a couple of hours work.
Observant readers will note that the "syntax" is somewhat inspired by OPAM.


I used the following to deduce the --host value to ./configure:
HOST=$(subst -cc,,$(notdir $(CC)))

I wonder, with the toolchain rename, is that always correct for us?

Yes. However I'm wondering if we want a bit more "infrastructure" that
makes it clear what target and/or bake configuration the user is building
packages for, and just does the whole lot. Or perhaps this is getting too
much like a packaging system? :-)

Other related posts: