Hi, On Tue, Aug 16, 2016 at 11:56:12AM -0400, Sam Hartman wrote: > I think live-wrapper is too immature to evaluate. I tried to evaluate > it as a replacement for live-build, but quickly concluded that it's too > early in the live-wrapper development cycle for me to be able to look > at. The documentation of live-wrapper 0.3, which I looked at, was very > sparse. It requires a lot of the directory structure where you run it > without clearly documenting that. There's some sort of customization > script that is needed, but it's unclear how that works.
I plan to have a whole weekend on live-wrapper this weekend. At present some paths are hard-coded although I'd like to get away from this. Work has been done recently in git that is not yet in the archive that is working to add support for live-installer. Currently we do not have easy customisation of the bootloader, but we do have working isolinux for BIOS and GRUB for EFI. > That said, if I had an existing Live Build project, I would not migrate > away from Live Build today. I'd expect to try and keep it limping along > through Stretch, fighting anyone who tries to remove Live Build, > possibly throwing in some Live Build bug fixing along the way. I'd plan > for probable migration in the Buster time frame though. It's not entirely abandoned, there are some still working on it in "maintainence mode" and there's no reason that new fixes can't be uploaded to the archive, but I don't see any new features being added. > I'd advise taking a careful look at my comments on vmdebootstrap, as I > think several of them may have implications for live-wrapper. [...] > vmdebootstrap is relatively limited in what it does, but IT WORKS. The > first time I ran it, it produced a working image. That's very unusual > in my experience of image creation tools. (: > vmdebootstrap is relatively focused in its image creation. It will loop > mount a msdos-partitioned image that it creates. It will run > debootstrap with one filesystem and an optional boot partition or UEFI > ESP partition. It will install a boot loader. > > It has a few custom hacks, mostly only for older releases. Fore example > you can request serial console, but not for stretch. You can request > dhcp, although be warned that with stretch you'll get systemd-networkd, > which may surprise you. In choosing packages for live images (see live-support) I've come across some of these issues already. The change to systemd and changes in essential packages have some odd outcomes not all of which have been normalised yet in live-wrapper. I'm aware of this though. > Extensibility is lacking. vmdebootstrap does one thing and does it well. This is why live-wrapper is to be a seperate tool and not integrated into vmdebootstrap. > It, like bootstrap-vz, is written in python2. This is due to dependencies not having Python 3 support yet, and is something that has been raised and is known. > It's telling that live-wrapper, even though it is also Python, doesn't > use vmdebootstrap as a library. It calls the command line script. > There's no other way you could do it: vmdebootstrap's extensibility > profile isn't good enough. This is maybe something that could be looked at in the future, maybe. For live-wrapper it's not been an issue so far. > Squashfs generation is supported, although you are responsible for > setting up live-boot and live-config. You may have a bit of fun > integrating that with vmdebootstrap's bootloader logic. (You might > think that live-wrapper would at least do that for you. Not yet. I'm > actually totally fine with vmdebootstrap's decision to push configuring > live-* up a layer, although I think it needs better customization hooks > to make that work well.) Working on this at the weekend. > vmdebootstrap doesn't have support for adding keys to Apt's trusted key > store. It doesn't have support for adding additional archives to your > sources. Debootstrap requires that all the packages come from one > mirror. vmdebootstrap doesn't provide a way to install packages from > another mirror later. Of course you can work around all that—in the > customization hook you're provided even. However, that's all critical > functionality you expect from a custom image tool. Some layer needs to > provide that for me if it's really going to be a complete solution for > managing custom images. > > SOURCE matters. If I'm building an image that I plan to distribute to > people, GPL and other licenses require that I distribute source. “But > Sam, you have the Debian mirror you used.” And so I do, until it > changes. I tend to distribute images longer than mirrors stay stable. > Yes, I could use aptly to snapshot my entire mirror. Yes, I could > coordinate s,m.something to figure out what packages make their way into > the image and snapshot only those package sources. Live Build gives me > this, and at least for custom images, that too is a requirement. live-wrapper will generate source archives. vmdebootstrap will give you a list of used packages that you can for x in blah dget... > I'd like to see some folks explore bootstrap-vz layered on top of > vmdebootstrap. Debootstrap would be responsible for taking Debian > packages and unpacking and doing initial configuration, just as it > always does. vmdebootstrap would be responsible for partitioning, > filesystem creation, bootloader installation and running debootstrap. > Bootstrap-vz would be responsible for tweaking the image, for providing > a framework for those tweaks, and for the schema/manifest language to > describe what it is that we want in an image. I'm not too familiar with bootstrap-vz but this sounds interesting. After the weekend, I'll have looked at these more and will be able to give a more details response. Thanks, Iain.
signature.asc
Description: PGP signature
