I agree in principle.
So far we've just been generating a patch and putting the necessary
lines to download/patch/compile the upstream package in
nestedvm/upstream/Makefile -- you can see that there are plenty of
packages in there like linpack, expat, gmp, etc.
Although this isn't pretty, we haven't yet quite gotten to the point
where there are too many packages for this to become unworkable. I
think that if the number of "nestedvm-ified" packages grew
substantially, a more formal packaging system would be justified.
Stepping back a bit, I think the ideal endgame would be if we could
simply "build Debian" on nestedvm. As I understand it, the two hard
parts of making this happen for a new platform are retargeting gcc
(done) and porting glibc (the part that remains to be done). I
believe it's pretty easy after that.
NestedVM has an edge on *BSD/Darwin/Cygwin here in that we can simply
declare glibc to be official once it has been ported. The fact that
glibc isn't the "libc of choice" on those other platforms is -- as I
understand it -- the reason why there isn't an "official" Debian for
any of them (Debian/kFreeBSD doesn't use the BSD libc).
That would get us not only the packaging infrastructure, but also the
build scripts for an impressive collection of packages.
- a