Forwarding Allan's mail at his request, and answering it :)
On 1/28/25 9:23 AM, Allan McRae wrote: > Hi Robin, > Hi Allan, > Can you forward this to arch-dev-public? I am not subscribed. > > > I have been using Arch almost exclusively in WSL for the past months. My > Arch machine died and I have not replaced it yet, so WSL on the work > laptop is what I have to work with. All pacman development currently > happens on WSL! > > It does bring its own set of problems, so we would need to have a clear > support policy of what is an Arch issue, and what is a WSL issue. Often > that is not clear! > > Things I have noted: > > 1) Importing from the docker image is good, but it strips a lot of files > (i.e. all documentation). It took me ages to work out why there was no > man pages! I do not think a WSL install should do that. > I guess we could install `man-db` as part of the "first setup" script. > 2) Logging in a root, setting up the user, the re-logging is not much of > a barrier to using Arch, so I do not think we need to automatically set > that up.Sure, that was just to illustrate how distributions usually use the automatic "first setup" script but we can use it the way we want of course.
> > 3) I do not enable systemd boot. I'm not sure what that causes me to > miss, but it does result in some errors on pacman upgrades from hooks, > so enabling is likely a sane default. >This is about enabling systemd support within your WSL distro, allowing to enable / start services via systemctl. Pretty handy!
> 4) I use WSL version: 2.3.26.0. I'm not sure why your notes say to use > a pre-release version >Version >= 2.4.4 brings support for "click-to-install" and automatic "first setup" script execution, which greatly simplify and improve the "installation" user experience (hence why I mentioned it). But this is not mandatory, such a tarball would still be pretty straightforward to install and use with WSL < 2.4.4. A single PowerShell command is enough to install and the "first setup" script would need to be launched "manually" at the first run, that's all.
> > As an example of a WSL specific bug, I battled for days with xfce4- > terminal settings. Any settings done in the settings manager are not > saved. I could not even get them to work by manually editing config > files in ~/.config/.... I work around this by having my taskbar > launcher point to: > > "C:\Program Files\WSL\wslg.exe" -d arch --cd "~" -- xfce4-terminal -- > font="Bitsream Vera Sans Mono 15" > > This may be due to lack of systemd boot (and thus dbus?). > > Also, getting click-through of hyperlinks from the terminal to a > (Windows) system browser was a pain. I need a symlink ~/bin/firefox to > '/mnt/c/Program Files/Mozilla Firefox/firefox.exe' and a custom > ~/.local/share/xfce4/helpers/custom-WebBrowser.desktop file. Even then, > I needed xfce4-settings installed for this to be recognised (even though > changing settings there does nothing!). > Ah, right. Thanks for bringing those up.I am myself only using WSL inside the default "terminal" environment and I personally do not export X11 or using any graphical environment / apps with it. So those are eventual issues I never had to deal with.
But that's a fair point. While I said in my earlier answer to George that I don't expect much WSL specific issues nowadays, exporting / using graphical apps could indeed bring its own fair share of potential issues. Although, I guess most of them would not be Arch specific and probably `wslg` (upstream) related?
> I have been keeping notes about my setup here: > https://gitlab.archlinux.org/allan/wsl > Thanks for the share! > > My conclusion is, WSL is definitely a useful tool, but brings its own > issues. Do we have the people-power or community to support it?That's basically what I'm looking for with this proposal. Maintaining the image itself would probably be a low effort but, indeed, gathering interest from some people (community included) around supporting it would be a prerequisite.
As I said to George in my response as well, I'm personally fine if we only officially provide low / limited support for it though, at least at first.
> > Cheers, > Allan Thanks for sharing good insight! -- Regards, Robin Candau / Antiz
OpenPGP_0xFDC3040B92ACA748.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
