Update DistributionInfo.json #9286
Conversation
Making adjustments for SLES-12 & SLES-15 as well as adding Tumbleweed.
| "StoreAppId": "9MZ3D1TRP8T1", | ||
| "Amd64": true, | ||
| "Arm64": false, | ||
| "Amd64PackageUrl": "https://wsldownload.azureedge.net/SLES-12_v1.appx", | ||
| "Amd64PackageUrl": null, |
There was a problem hiding this comment.
@craigloewen-msft : FYI we should upload this package to the CDN
There was a problem hiding this comment.
(I know your comment wasn't for me, but ...) I opted to remove this because I don't know what "_v1" is in reference to and I can't discern if the --install will key in on the StoreAppId (which I can predict which version will be installed based off the partner portal) or this Amd64PackageUrl which SUSE has no control over.
There was a problem hiding this comment.
@sbradnick: This package URL is used when wsl.exe --install is called with --web-download and on server SKU's, so if this is removed, all of these scenarios will not work.
There was a problem hiding this comment.
I don't disagree, but SUSE doesn't [have the same level of] control over that PackageUrl and IIRC when I checked ahead of entering this PR, the SLES-12_v1.appx wasn't something we really want to offer up anyway (off the top of my head, I can't recall that 9MZ3D1TRP8T1 == SLES12SP5 =? SLES-12_v1.appx). Last references I see in chats w/ my teammates is it being SLES12SP2 which isn't something we want to offer up; and the files contained in that .appx are from 2017. The /etc/os-release contained in install.tar.gz also point to SLES12SP2.
Basically, it feels like side-stepping the Store in the sense that we'd like to offer up a curated list of supported distros (as listed by: https://apps.microsoft.com/store/search/suse?filteredCategories=Developer%20tools) and this doesn't fit into that (as evidenced by openSUSE-42 being listed for an extended period of time by --online but having been EOL'd by SUSE since July 2019) and doesn't offer much flexibility outside of people installing from github.com/microsoft/wsl/releases AFTER someone such as myself enters a PR to get it fixed.
I'd argue against the idea of a Store method to install distros AND this whole DistributionInfo.json method by --online unless Microsoft is going to give development partners like SUSE more control over it. MAYBE if it was a mirror of Store offerings, straight up, it'd be ok. The Store may be heavy handed and take lots of clicks to implement, but it's a repeatable process w/ understood results - this seems like a wild-west approach and those who can change it aren't necessarily versed in what SUSE is doing and what should be available. There are more than a few Distros out in the wild - so I can understand that - but my team is more than happy to take this on 😃
There was a problem hiding this comment.
That's understandable. Maybe an acceptable middle ground would be for SUSE to host its own .appx and have a URL pointing to SUSE's CDN's here.
@benhillis / @craigloewen-msft: what would be your thoughts on this ?
There was a problem hiding this comment.
I'm not sure SUSE has much interest in a parallel install method like this. Speaking for myself, as a Linux user since the late 90's - yes, CLI is my preference - but we're getting wildly different experiences between using the Store as a source and this idea of --web-download maintained by someone who clearly isn't a mainline SUSE user; that's not a dig at anyone, but as evidenced below - what exists now makes no sense whatsoever.
As the current DistributionInfo.json stands before my PR - running wsl --install SLES-15 (which doesn't have a PackageUrl) uses 9NJFZK00FGKV which is actually Leap 15.1 (an EOL version) - this is TERRIBLE and confusing on many levels (i.e. requesting "SUSE Linux Enterprise Server 15SP?" (SLES) and getting "openSUSE Leap 15.1". No matter what someone would do w/ this installation method/source, they'd get an EOL distro installed).
It does appear --web-download doesn't work when a PackageUrl isn't present (I agree with you there - and it seems like a nice-to-have when it's setup properly), but there's little precedent, for SUSE at least, that this is working "as intended" as the results are either NOT what was requested based off the naming or produce a "Catastrophic failure":
PS C:\Users\scott> wsl --install SLES-15 --web-download
Catastrophic failure
Error code: Wsl/InstallDistro/E_UNEXPECTED
And by this logic, SLES-12 would appear to be CORRECT if done via wsl --install SLES-12 but INCORRECT if done via wsl --install SLES-12 --web-download (You'd actually get SLES12SP2 because of "Amd64PackageUrl": "https://wsldownload.azureedge.net/SLES-12_v1.appx").
Changing: `"Name": "Tumbleweed",` to `"Name": "openSUSE-Tumbleweed",` per request.
There was a problem hiding this comment.
Mislicked.
This change should be superseded by: https://github.com/microsoft/WSL/pull/9562/files
|
Closing in favor of #9562 - thanks! |
Making adjustments for SLES-12 & SLES-15 as well as adding Tumbleweed.