ELBE does this automaticly by creating ISO images containing the debian source and binary packages of the target image and the machine it was built on, including the elbe tool itself and the XML needed for regenarting everything.
That's some nice housekeeping, actually.
Which tool do you mean?
Sorry, I wasn't clear... I was talking about apt-get/debootstrap, which resolve all the inter-package dependencies on their own.
Definitely, this is one of many reasons why we decided to use Debian in our embedded projects.
I just wish so much of the system didn't depend on Perl! Not only does using a filtering language for procedural work make my head hurt, but the infrastructure it requires on the target at runtime is a significant contributor to Debian's base footprint.
My targets ship with apt-get et. al, since most of my clients want that as part of their upgrade mechanism. Your mileage may vary.
I think that's not true. E.g. for foreign architectures we use qemu-user*static inside the chroot for the 2nd part of debootstrap. Another version of qemu may lead to a crash in a post-install step and lead to a different image.
AAAhhh, now your approach makes more sense. I still don't really like it :-), but it does fit with your overall intent.
I let the target do its own second-stage bootstrap on their first boot, which is how I'm able to sidestep QEMU and all that other machinery on the development host.
MTD utils or parted used from the host system are another part of the image generation process that is not covered by archiving only the packages for the target.
True. That's the only reason I use guestfish: to create non-ISO target images of a precise layout that I can then just dd to an SD card or whatever else the target uses.
So i think it's always necessary to backup the workstation, that was used for image generation. The method you choose depends on how important the regenartion of the images is.
Sadly, I'd have to agree with you here. Debian is great, but time marches on and rarely looks backwards...
Yes, we use this argument, if elbe is compared with cross-build systems like buildroot or open-embedded.
Buildroot was superb in its era, and it's still necessary for some really nasty, very infrequent situations.
Apart from that, though, the whole "build everything from source" approach is a cancer on our industry. I'm looking at you, Yocto.
Another thing in elbe are the different copy modes. In default mode the
complete output of 'debootstrap' is in the image. In 'diet' mode, only
the packages from the pkg-list inside the xml file and their dependencies are in the image.
My approach is kind of like your "diet" mode, but "diet-plus". I can throw in extra packages during the bootstrap process, but to kick everything off I have to provide it a top-level meta-package that calls out the key requirements of my base system. I change your equivalent of "modes" by changing which top-level metapackage I throw at debootstrap.
The risk is, that post-install scripts may fail, because Debian policy says, all essential packages need to be on a system. What may not be the case in this mode. In this mode we often need some 'finetuning' rules and addtional config files from the XML embedded archive to get a booting system.
Aaah, another reason why our approaches differ.
My systems always conform to at least the spirit of the Debian policy for essential packages. Plus, EVERYTHING on my systems MUST come from a package, so the "finetuning" is handled upstream.
Upside of my approach is, I know that none of that fine tuning doesn't change between testing and release. And during testing, as I change things I can just apt-get them to the device under test and know that it's getting exactly what will go into the release build.
And it's not really a 'Debian system' with apt & co.
Yeah, I can see that we're talking about different things, since my systems always ARE fully-capable Debian systems.
I'm currently looking how it is possible the share source with vmdebootstrap. Either integrate the tool into elbe. Or wrapping out image generation into a python module that can be used by both tools.
Anything that breaks the packaging concept is pretty much a non-starter for Debian proper, I would think, since it risks breaking the package dependencies that keep the system together.
That would include bashing around in the target filesystem post-boostrap like your scripts sound like they're doing. Which, to be honest, is also what the Debian Installer does for /etc/network/interfaces, etc.. I don't have to deal with those problems, since I always have the schematics so I always know what the contents of the package that gives me my target-specific /etc/network/interfaces file should look like. :-)
Packaging the own application is typically no showstopper. It's is defintely easy.
Honestly, there was a time when I feared it. That was before I learned about it, though. Nowadays, it's almost as habitual to me as a Makefile is. :-)
b.g.