On 1/7/20 11:16 AM, Kevin Kofler wrote:
Chris Murphy wrote:
Stacked images on the same media functionality is in the kernel, it's
not complicated, it's well tested, doesn't require any gymnastics in
the initramfs - your bootloader entries can each point to different
root=UUIDs and image assembly is figured out entirely in kernel code,
no special handling in the client side deliverable. Yes the image
creator needs to know some things to achieve this.
Why stacked images? Consider a single base.img that's maybe 1G, and
now you don't have to do separate composes for server, cloud, GNOME,
KDE, Cinnamon, LXQt, Astronomy that repeat a lot of the same steps,
including expensive steps like compressing the same things over and
over again. Just do a 'dnf group install' tacked onto that base.img,
the work being done is custom for that output, rather than repetitive.
Not complicated. It would be fast enough that the high level variants
could be composed on demand. Seconds. It'd be fast enough to queue it
for download within the hour.
Then how do you deliver the stacked images? Either the user still needs to
download base.img + the specific image the user actually wants, either as 2
downloads (but then how does the user reliably get them onto bootable media?
Surely you don't want to require 2 media!) or as 1 combined download, or you
ship one image with base.img and all the specific layers at once, which will
waste a lot of download size for all the images the user does not care
about. I do not see what use case would be served by stacked images.
What would be a much more useful feature is hybrid netinstall, i.e.,
allowing liveinst to netinstall additional packages on top of the installed
live image. See the Calamares netinstall module (e.g., on my old Kannolo 27
images, as long as I don't have newer ones) for how the user experience can
look like. And that requires only installer support, no file system or
compression support.
At first I did think the same thing as you did, that it would have all
of them. But my understanding of what he was suggesting is similar to
your suggestion. There's a base image and then for each spin, there's
an extra stacked image that contains whatever extra is needed for that
spin. So there's a separate iso for each spin, but each one has the
base image plus (at least) one other.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
