There are a bunch of About topics which are very windows specific and need to be culled from the LInux distribution.
More generally, we need to have a mechanism for general About files, WIndows-only About files and Linux-only About files.
Examples:
about_Eventlogs
about_Group_Policy_Settings
about_PSSnapins
about_Windows_RT
about_WMI
about_WMI_Cmdlets
about_WQL
about_Workflows
Yeah, there's some (like Workflows, Snapins, and Workflows) that need to go away altogether. Then there's the Windows vs. Linux ones. This needs to be done by 6.0.0 for sure.
Rather than remove, is there a way we can make about topics conditional to the OS PowerShell is running on?
Module authors will run into this where an about topic may not apply to an OS or they will want to have different topic content depending on the OS. It sure would be nice to have a single, cross-platform module distribution.
Maybe use a module dir structure like the following (if it exists) to serve up OS-specific help:
help\Windows
help\Linux
help\macOS
Should we move the issue in PowerShell-Docs repo? /cc @SteveL-MSFT
@iSazonov I don't believe the help documents nor PowerShell Help has a mechanism to differentiate help for a specific OS. We need to add that capability first before addressing in Doc repo. cc @adityapatwardhan
Is this something that Update-Help could do? Allow Update-Help to determine what OS it's running on and clobber the "abouts" that aren't appropriate?
@sdwheeler - Is the applicable OS part of the new schema?
I had proposed adding metadata for platform that could be useful here. I hadn't thought about it for About_ topics but no reason not to include it. The hard part building platform specific cab files.
I think we should include the help for all platforms but have Get-Help filter the view to the platform and have a parameter to select the platforms you want to see.
I agree with @sdwheeler that we should have one Help package for all platforms. On Windows I can need to read Unix topics and vice versa. (Also there are remoting scenarios.)
I do not think we need new filter/parameter for the same reason.