Merge lp:~sil2100/livecd-rootfs/core-series-per-suite into lp:livecd-rootfs
Status: | Merged |
---|---|
Merged at revision: | 1704 |
Proposed branch: | lp:~sil2100/livecd-rootfs/core-series-per-suite |
Merge into: | lp:livecd-rootfs |
Diff against target: |
34 lines (+16/-0) 2 files modified
debian/changelog (+8/-0) live-build/auto/config (+8/-0) |
To merge this branch: | bzr merge lp:~sil2100/livecd-rootfs/core-series-per-suite |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Steve Langasek | Approve | ||
Review via email: mp+356040@code.launchpad.net |
Commit message
Decide what model assertion series to fetch depending on the suite. Use 16 for xenial and 18 for other series (bionic+). This enables core18 image builds.
Description of the change
Decide what model assertion series to fetch depending on the suite. Use 16 for xenial and 18 for other series (bionic+). This enables core18 image builds.
The decision to do it per-series comes from actually how cdimage determines what core series to use (with the core_series property). Since cdimage bases it on the distro series, I did the same here. We might think about adding yet another environment variable for this purpose but I would personally not want that. We already have enough parameters we're passing over to livecd-rootfs.
NOTE! It's best not to merge this just yet since apparently there are no official 18 series model assertions in the store yet. I have poked mvo about it.
You are right regarding some problems with this approach. I think ubuntu-image should be good-enough in xenial for building images (we'd have to check if the deprecated mkfs.ext4 doesn't mess with the final filesystem too much) as I'm testing build and boot capabilities for amd64 with every release, but livecd-rootfs is completely outdated there. I didn't expect it to be missing even the basic ubuntu-image support.
Currently I see four ways of resolving this:
1) Making sure xenial-generated ubuntu-image images are ok and backporting livecd-rootfs changes for u-i and core series selection to xenial.
2) Switching to a new, separate environment parameter to steer which core series to use.
3) Using a different environment parameter from the existing ones to decide the core series. We could, potentially, use for instance SUBPROJECT. Currently for core images it's not used and maybe core series could somewhat fit that purpose? Hard to say.
4) Ugly but easiest way: deciding that we'll be using bionic for core16 and cosmic+ for core18.
I have prepared an MP for 1) [1], but I somehow suspect that this approach might be a bit troublesome. 2) seems like a bad idea, I remember no one actually wanted a new variable. We've got enough of those already. 3) might be good but this all depends on what uses we have for SUBPROJECT - or maybe there's a different variable we can use?
Lastly, there's 4). It's the easiest as it will not require much changes anywhere. The problem I have with it personally is that it's quite non-intuitive. Like, the binding that bionic -> 16 and cosmic+ -> 18 has no real basis anywhere and someone new, trying to build a new image, might just build the wrong thing.
Personally I'd prefer 3) or 4). What do you think? Which way should we go?
[1] https:/ /code.launchpad .net/~sil2100/ livecd- rootfs/ xenial- ui-support- and-core- suite/+ merge/356150