[SRU] Allow building WSL images of Focal in the new format

[Carlos Nihelton]

[ Impact ]

 * Previously, WSL instances relied on a very lightweight build pipeline which was using the CPC image.
In 22.04 we did a first step to have WSL has its own project in livecd-rootfs, with its own seed and image to produce a rootfs, while leaving Focal for later.

 * Later, changes to livecd-rootfs and related packages for Noble and later were implemented to adapt the images to the new format promoted by WSL that allows distributions to no longer rely on MS Store, which is becoming deprecated for WSL. Those changes are in the process of being backported to Jammy.

 * Focal is the only LTS still supported via Ubuntu Pro that lacks those image building capabilities.

 * This Stable Release Update request aims to bring Focal to the current state of the art build pipeline of WSL images, allowing us to host the final artifacts in Canonical's infrastructure and no longer depend on MS Store.

 * We thus need to promote 'ubuntu-wsl' as its own project in 'livecd-rootfs' for focal, implement the same image building hooks already existing in Jammy and update 'ubuntu-meta' to reflect the changes already implemented in the seed related to this project.

[ Test Plan ]

1. Build a new Focal image for WSL on Launchpad.
  -> we should see one image ending up with ".wsl" for 20.04 image

A. New installations:

1. Ship a cloud-init file to touch a file on disk on `%USERPROFILE%\.cloud-init\Ubuntu-20.04.user-data`
2. Download the image made available from above, double-click install it on a Windows machine with WSL 2.4.4 and later, then:
-> Check that basic shell commands works
-> Check that no MoTD messages complains about cloud-init failure
-> Check that the file from the cloud-init profile was applied
-> Run systemctl --failed and ensure nothing is listed related to WSL specific configuration itself
-> Pro attach the machine and check that it’s attached

[ Where problems could occur ]

* Most of the issues could happen on initial boot. It will be really easy to spot any issues there with the previous test plan.

* The set of updated defaults in 20.04 only affect WSL targets, so other platforms remain unaffected by the proposed changes.

[ Other Info ]

 * As already explained in LP #2115426, despite Focal being out of standard support, we need to align its build pipeline to the current state of the art (implemented for Jammy and later), as MS Store is being deprecated.

 * All the changes in the packages tracked by this SRU bug are related to each other and need to land together otherwise building a WSl image of Focal would fail.

 * This report relates to LP #2080223 and LP #2091293, but the changes needed for 20.04 are more complex (as already mentioned in the former), thus I'd rather do it in a dedicated SRU.

* The WSL seed for Focal was already aligned with Jammy and later as we can see in [this commit in the ubuntu-seeds repository](https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?h=focal&id=70d0bae95ea450b5cb18325d52a56b9e41be9465)

* Bug https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2136341 was opened including 'wsl-pro-service' into Jammy, preventing problems for distro upgrades from a new Focal image (built after those patches are released).

[Andreas Hasenack (ahasenack)]

The SRU team is fine with pushing out new WSL images for focal, and also the new wsl-* deb packages which have landed in proposed or updates already even.

The reason I'm not voting on the MPs specifically, is because I don't know the details about the machinery that produces such images, and where other changes are needed in order to produce such images, WITHOUT disturbing anything else focal-related that is not WSL.

Do we also have to SRU ubuntu-meta? I don't know, and I ask for other reviewers to chime in. The concern of the SRU team is, as always, avoiding regressions, specially to non-WSL users. So the goal is to produce these new WSL images for focal, without disturbing the non-WSL users of focal.

[Julian Andres Klode (juliank)]

An upload of ubuntu-meta to focal-proposed has been rejected from the upload queue for the following reason: "Removal of wslu potentially breaks existing user workflows".

[Julian Andres Klode (juliank)]

To provide more context, assume a user installs a new machine and focal on it to match their existing one, they expect that everything that worked in the existing one works in the new one, so removing a package is a no-go.

The rest is debatable

[Jean-Baptiste Lallement (jibel)]

@juliank, we really want to drop 'wslu'. It's a hackish set for scripts that is unmaintained and unmaintainable and discontinued upstream. There is more risk to keep it than dropping it.

Please reconsider your decision.

[Robie Basak (racb)]

Carlos pinged about this on Matrix (https://matrix.to/#/!slcYrFqWytcsbPzMxA:ubuntu.com/$Cy36RxSdvU-BacSvWG7H2hJSIaxNPV5E4GoPSghaJJk?via=ubuntu.com&via=matrix.org&via=matrix.debian.social):

Me:

> So wslu provides the wslview tool for example, right? What about users who use it? Will they lose that functionality in a new image?

> I use it for example to open urls in the browser from mutt inside WSL.

Carlos:

> If we proceed, yeah, users would loose wslview and other features provided by wslu in a new image. The problem with that package is that it's unmaintained at this point, the upstream discontinued the project and org in GitHub. Your specific use case is covered by the terminal itself. Instead of running wslview <URL> one can simply ctrl+left-click over the URL and that will be open in the Windows browser as well. But I also reckon this is just one use case and users might have use cases we don't have alternatives for.

So it seems to me that:

1) This will actually regress users, so isn't acceptable from an SRU perspective.

2) You already committed to maintaining the wslu package for the lifetime of the release when you took the action to add it to the release. Saying it is "unmaintained" to me only says that you wish to renege on the commitment that you (CPC/desktop) yourself made to maintain it in the first place.

3) Therefore there is nothing to reconsider.

Nevertheless I will see what the SRU team think about this in our next meeting.

[Andreas Hasenack (ahasenack)]

> It's a hackish set for scripts that is unmaintained and unmaintainable and discontinued upstream.

The MIR[1] for this package stated back then (2019):

"""
Maintenance
===========
- Actively maintained upstream:
  https://github.com/wslutilities/wslu
- Ubuntu Foundations Team is subscribed to the bug reports
- I'm the only listed maintainer of the package but it is a simple package and does not need a lot of attention.
"""

It was demoted to universe some point after focal (in jammy it's in universe already), but Focal is still an LTS and under ESM now. There is definitely an expectation to not "just remove it".

It even has an SRU exception[3] for it. Confidence was very high.

Was it a "hackish set of scripts" back then as well, or did it deteriorate since then?

There are very few cases[2] for SRUs to remove a package, and much less for a package in main. None of the ones listed in [2] were actually in main, so removing wslu would really be something extraordinary, requiring more justification than what was provided.

1. https://bugs.launchpad.net/ubuntu/+source/wslu/+bug/1820769
2. https://documentation.ubuntu.com/project/SRU/reference/historical-removals/
3. https://documentation.ubuntu.com/project/SRU/reference/exception-wslu-Updates/

[Carlos Nihelton (cnihelton)]

Thank you all for the attention on this subject. Enlightened by the reasoning exposed by the SRU team, we restored the 'wslu' package in the focal seed (see MP https://code.launchpad.net/~cnihelton/ubuntu-seeds/+git/ubuntu/+merge/495886); the branch proposed to ubuntu-meta for this SRU has been refreshed from the latest state of the seed and its ready for sponsorship.