On Mon, Mar 24, 2014 at 3:42 PM, Antti Kantee <[email protected]> wrote: > 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.
Rolling releases are generally called releases, while snapshots are just stuff you push out. The main thing from the packaging point of view though is that (certainly have had issues with rpm in the past) is the numbering scheme, snapshots are usually rumpkernel-20140314-1 while a release will be rumpkernel-0.1.2-1 and if you change from using one to the other it causes havoc as 20140314 is much larger than 0.1.2 so you can't upgrade to 0.1.2. Given that x.y.z semantic versioning (with ABI changes signified by incrementing the big number, except before 1.0) is standard, we should use that, and change as soon as possible before anyone starts using the packages, which was why I wanted to get that sorted out now.... > 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: Note that not all packaging splits devel and non devel, so it might be simpler just to think of the base package, and let the distros split up (they may also split up doc and debug and all sorts). I think it is better to just start with one package per source repo for now, as we already have granularity by repo. If you get a few extra files or libraries you don't need it is not the end of the world, it is easier to split up later. > 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. I would make one package for now, eg called netbsd-rumpkernel > 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? I would be inclined to make all these one package. netbsd-userspace-src is just source code its not a requirement to run anything, so an end user will never need to install it, which is who packages are aimed at. > drivers (e.g. dpdk-rumptcpip): buildrump.sh-devel > be able to build drivers without having to run buildrump.sh These should probably match dpdk releases, whatever they do. > fs-utils: buildrump.sh > the file system access utils. parts of this could probably be converted > to rumprun. fine. > > 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? Again if it is packaged it needs to match Xen ABI changes. However it is not much use without linking your code to it, so unless it is packaged up a bit more it should stay as source only for now. Hopefully at some point it can share a build pattern with rumprun so you can build for both easily. >> 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. ok. >> 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). I was under the impression that Travis only supported PPAs, but I may well be wrong, as I havent tried anything else. The documentation doesn't really say, I assumed that sudo was limited to certain commands... Will find out. > 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. That doesnt necessarily need a submodule, the only advantage is it does give a known working tag. Another option is for the buildrump to have a simple installer to /usr/local so you can just do something like clone && make && make install in traditional style and then use that copy, again by default (specifying paths is the annoying bit really). eg for ljsyscall I would probably expect the two common use cases to be either against a rump kernel release or against netbsd head or a modified head, so I think the manually updated git submodule is probably not very useful - I might run travis against stable and head though, not sure). > ... yea, difficult subject. Does anyone have ideas on how to break it > down into bite-sized chunks? One email thread per part of this? j ------------------------------------------------------------------------------ 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
