Guys:
On Fri, Jan 22, 2016 at 2:34 AM Manuel Traut <[email protected]> wrote: > > 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. -- Bill Gatliff Embedded Linux training and consulting [email protected] (309) 453-3421
