FS#75545 - [dotnet-host] PKGBUILD adds a non-existent and out-of-boundary folder to PATH

Attached to Project: Community Packages
Opened by drws (drws) - Monday, 08 August 2022, 08:50 GMT
Last edited by Maxime Gauduin (Alucryd) - Thursday, 11 August 2022, 09:28 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Maxime Gauduin (Alucryd)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

The package provides a drop-in script for /etc/profile.d which adds "$HOME/.dotnet/tools" to PATH:

https://github.com/archlinux/svntogit-community/blob/676f85c4f9cba7fd4d8faba2fa05b459a94d5fb4/trunk/dotnet.sh#L4-L9

I believe this is unclean and contrary to FHS. For example, I don't allow any binary execution in my $HOME and even if I did, I'd definitely not want to see the whole binary in the PATH. Microsoft binaries are barely welcome anywhere in my system, let alone my home folder (well, except for "$HOME/.local/share/Trash").

Setting the trash joke aside I believe the solution is somewhere along "/opt/dotnet-host/$USER/".


Additional info:
* package version(s) <= 6.0.6.sdk106-1


Steps to reproduce:
1. echo "$PATH"
This task depends upon

Closed by  Maxime Gauduin (Alucryd)
Thursday, 11 August 2022, 09:28 GMT
Reason for closing:  Not a bug
Comment by drws (drws) - Monday, 08 August 2022, 08:55 GMT
Or an even better path: "/opt/microsoft/dotnet-host/$USER/bin".

Also, forgot to mention in the description that the "$USER/.dotnet/tools" folder doesn't even exist on my system, but dotnet.sh script adds it to PATH anyway. I believe this is a second issue with the script-
Comment by Toolybird (Toolybird) - Monday, 08 August 2022, 22:05 GMT
There is a "Tip" in the wiki [1] about this which implies it is needed.

[1] https://wiki.archlinux.org/title/.NET#Installation
Comment by drws (drws) - Tuesday, 09 August 2022, 15:31 GMT
The tip is a consequence of the mentioned script, so there is no second issue. But the original issue that package expects you to host binaries in the home folder remains.
Comment by Maxime Gauduin (Alucryd) - Thursday, 11 August 2022, 09:28 GMT
Whether you like it or not, that's where dotnet installs its tools, so that's where we need to point $PATH [0]. I'm not sure why it bothers you, you said yourself that the directory doesn't exist for you, and that your home is noexec, so it looks like a non issue to me. Plus the path is added last so it's fairly innofensive, and a way better solution than answering hundreds of emails because users don't bother reading the wiki, we are not a call center.

What you propose would require users to specify `--tool-path` every time they want to install a tool and manage permissions on an outside directory themselves, that's an infinitely worse user experience compared to what's working out of the box today. Except if you noexec your home, but at this point you should know what you're doing and should be prepared to and capable of dealing with the consequences.

[0] https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-global-tool

Loading...