On 22/03/14 14:18, Justin Cormack wrote:
> Some random thoughts on packaging:
Thanks for raising this difficult but important subject. I fear that
this will be a long email ...
> We need to keep packages updated, which basically means we should do
> releases not snapshots (the last snapshot was a release really after
> all). But means changing to proper release versioning before there are
> two many packages around. Probably want to match up rumprun releases,
> as they need to be in sync.
I'm not sure what the difference between a snapshot and a release is ;)
I think I picked the name "snapshot" for the tarball because I think
that due to continuous testing and integration we have a "rolling
release" anyway. However, if there are marketing implications, I don't
mind using the term "release" instead of "snapshot" from now on.
If we're going to be pushing for releases and packages in a full-stack
fashion, we should figure out what we want.
I'll use the current github repo names to sketch these and their
dependencies:
buildrump.sh:
kernel components (does librumpuser/client go here or not?). We could
also call it buildrump.sh-posix if we want to include hypercalls.
buildrump.sh-devel:
headers and build tools. I'm not sure how much of the NetBSD source
tree would be required, hopefully just src/sys/rump and src/share/mk.
netbsd-userspace-src: buildrump.sh-devel(?)
userspace libs
netbsd-userspace-src-devel:
headers for above. maybe should depend on buildrump.sh-devel
rumpremote: netbsd-userspace-src (+ -devel)
remote tools for rumprun
rumprun: buildrump.sh, netbsd-userspace-src (+ -devel)
I'm actually not sure what this package would do. Provide some .so's?
So it would effectively be a devel package?
drivers (e.g. dpdk-rumptcpip): buildrump.sh-devel
be able to build drivers without having to run buildrump.sh
fs-utils: buildrump.sh
the file system access utils. parts of this could probably be converted
to rumprun.
So, if I paint with a bigger brush, it looks like packages should give
1) development building blocks, like you point out later in your email
2) end-user software.
The still leaves out things like rumpuser-xen, which doesn't quite fit
into the above. Do we care about that or not? Should it be left as
source-only?
> We should standardise the names, eg pkgsrc has rump, while OBS is
> netbsd-rump. I would think that "rumpkernel" was probably best, then
> rumpkernel-rumprun etc. (Might even be inclined to rename the
> buildrump.sh repo to rumpkernel).
Yes.
In pkgsrc it's probably called "rump", because back when the package was
created, rump kernels were called RUMP (which has not been the case
since something like 2010 or 2011). Arnaud can confirm or deny if my
assumption is correct ;)
I like the xbps package name best: netbsd-rumpkernel. It 1) states what
is provided 2) states what OS provides the kernel drivers. In the
future we may very well see other OSs providing their drivers as rump
kernels, even if not very soon.
buildrump.sh is called buildrump.sh because it started out as an
experiment to quickly facilitate routines which could later be merged to
NetBSD's build.sh. With buildrump.sh now being half the size of
build.sh and containing no overlap, I don't think it's a good goal
anymore; it would just make it harder for people without a NetBSD commit
bit to contribute. So, while I am getting a bit tired of renaming
everything all the time, what you suggest may make sense. But let's map
out a complete plan before taking action.
For the record, at least if I'm allowed to decide, in written language
the official name of a rump kernel is "rump kernel", not "rump" or
"RUMP" or any cute acronym thereof.
> An Ubuntu PPA would be a good thing, as thats the only thing Travis
> accepts easily. Should just be able to build the OBS packages there,
> will look into it. I would like to not have to build rump for all my
> projects in Travis etc.
>
> It might be worth bringing the packaging stuff (config files etc) into
> the repos (at least Debian has now changed their policy which was that
> repos should not have it in due to conflicts, now they seem keen on
> upstreaming it).
>
> It would be good to start to try to upstream some of these, but doing
> distro quality packaging for Debian and Fedora is quite a pain now, so
> maybe need to find someone interested.
Maybe we should first shift towards using the OBS builds for Travis and
other automated testing systems, and see how that works out. I'd rather
leave the rest to the experts of packaging to suggest and decide (which
is probably everyone except me on this list).
One thing I do like about git submodules, though, is that as a developer
I am not forced to need/use a packaging system to be able to build some
leaf functionality, provided I don't mind throwing 10min CPU time at it.
It would be nice to preserve this "single command to build on a
barebones host" quality.
... yea, difficult subject. Does anyone have ideas on how to break it
down into bite-sized chunks?
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
