On 24/03/14 17:29, Justin Cormack wrote: > 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....
I think an ABI specifier falls into the category of "nice idea, but in reality wishful thinking". For one, we'll have to bump the major number every time the NetBSD kernel version is changed (and that's quite often). Second, it's not uncommon for kernel ABI changes in NetBSD to accidentally go unnoticed. Third, we're not just limited to the kernel, but changes with rump kernels too (e.g. the remote syscall protocol, hypercalls, ...). We'd end up bumping the major with every release, and that's what a date-based specifier does in addition to conveying useful information; e.g. 20140314 will not contain NetBSD driver changes _after_ 20140314. Short of lending itself to "release branches" (which I also see as wishful thinking), I don't see a benefit in a [12...] numbering scheme, and therefore I vote to preserve the current one. >> 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 There are at least two immediate problems that will stop a joint package from happening today: 1) packaging up the tools built by buildrump.sh is not supported 2) I'm not sure how to codify where the packaged tools can run. Since the tools are for a large part wrappers to the toolchain, they're dependent on the toolchain they're built for. I wonder if solving those problems is actually useful? I'm tempted to lean in a direction recommended by a packaging expert. >> 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. Sounds reasonable. >> 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. The dependency flow isn't strictly unidirectional. Sometimes, it makes sense to roll a new driver release due to improvements or (security-)fixes in rump kernels. >> 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. I was thinking about the problems in terms of how hypercalls are different. >> 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. Isn't it possible at least to wget the .deb and dpkg -i it? >> 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). Like I said, would like the preserve "single command to build on a barebones host". The mechanism can be different, if an alternate mechanism brings additional benefits. >> ... yea, difficult subject. Does anyone have ideas on how to break it >> down into bite-sized chunks? > > One email thread per part of this? Maybe more discussion is the wrong way to go. From these two mails it almost sounds like there need to be some SIGpkg that just attacks the problem of turning the current situation into packages by figuring out what the constraints are, hacking around/with them, and just getting the job done. ------------------------------------------------------------------------------ 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
