Re: Comments on live-build, vmdebootstrap, bootstrap-vz, and live-wrapper
On Tue, Aug 16, 2016 at 11:56:12AM -0400, Sam Hartman wrote:
> Hi.
> I recently finished putting together a custom image of what amounts to
> stretch for work. Today, this is mostly not a cloud image, although
> that's expected to change for our future customer deployments.
Thanks for your detailed report!
> bootstrap-vz
> Secondly, with some irony, I realized that it would be annoying for me
> to add my own customizations to the image. Bootstrap-vz makes it easy
> for bootstrap-vz developers to add new tweaks, but makes it challenging
> for custom image builders who don't want to hack on the bootstrap-vz
> sources. I really want something like the vmdebootstrap customization
> script where I can run a chunk of my shell or Python code
Ideally the codebase should be inviting enough that it should make you
*want* to bring your improvements as part of the upstream codebase, or plugins
that adapt neatly to it. Alas that doesn't seem to have been the case for
you and bootstrap-vz. When building images, I tend to start with creating
the image by hand - in shell. So shell script comes down naturally as
what one would use for building images. However, as you noticed with
live-build later, unstructured shell scripts have their limits.
sidenote: This touches the subject of how the four freedoms of software
as in DFSG remain academic if you can't exercise them in practice due
to bad usability and too hard to understand code structures. As detailed
more articulately by Matthew Garret at https://mjg59.dreamwidth.org/32686.html
> A Suggestion
>
> As a user, who would love to see Debian be great, but who has no
> political skin in any previous battles, I'd like to offer a suggestion
> for something to explore.
>
> 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 a big fan of much layering. Both bootstrap-vz and
vmdebootstrap (and most other tools too) implement partitioning as parted
calls. A script in between doesn't add much value but obfuscates what
parted call have been done.
Installing bootloader is more complicated, but boils down often to
running grub-install (or doing something similar by hand) with
right mounts in place.
> We'd probably have to give up some of the tweaks we have, and add
> support either for plugins for some of the more basic tweaks directly
> into vmdebootstrap. As an example, vmdebootstrap would almost certainly
> need to support raw images without a partition table.
> However, I think an clear interface between vmdebootstrap and
> bootstrap-vz would make it easier to audit what was being done to an
> image and might improve both products.
I think we should look into pushing customizations and tweaks into
packages. Say ec2-defaults, virtualbox-defaults etc. The key benefit
being that everyone gets same settings regardless of what tool they
used to create the image, and everyone gets new better settings with
apt-get upgrade ( rather than via switching to a new image).
> I think we should do something. If there's one thing I hope you take
> away from this message, it's that none of the options I explored is
> ready—probably not even for Stretch. Will we have a regression in our
> custom image functionality Stretch over Jessie? Will we have a solution
> in time for Stretch? I don't know the answers to either of those, but I
> hope that we can come together in a spirit of cooperation and work on
> those questions rather than focusing on parallel, independent paths.
Wise words.
Riku
Reply to: