Fix directory ownership of RPM packages

[dagood]

dotnet/docs#14339 (comment)

I had a look in the Microsoft rpms (using rpm -ql <rpm> and seeing if the folder shows up). It seems like this is taken care of mostly. I saw to cases where it isn't: No package owns the packs folder. Also templates, which are part of the sdk package, only list files. The templates, and templates/<version> folder don't show up.

Something in Core-Setup should probably own packs.

[dagood]

We need to figure out if this impacts major scenarios, might not fit 3.1 GA.

[dagood]

Potential problems caused by this issue are described at https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/, headers:

• Inaccessible Directories
• Directories not Removed [when uninstalling]
• Directories cannot be Verified [with rpm -V nor rpm -qf]
• ./configure Scripts can Fail

Our targeting pack RPMs are generated using infra that doesn't account for this, I think:

https://github.com/dotnet/core-setup/blob/57fa3b22a41db5752d8c85762336a9a22ec235ec/src/pkg/packaging/rpm/dotnet-sharedframework-rpm_config.json#L42-L45

If that's right, GetRpmInstallerJsonProperties needs to be improved to add this ownership list.

I believe we should fix in 5.0 and consider as a servicing fix for 3.1.

Installing then uninstalling dotnet-sdk-3.0 leaves these dirs around (we need to fix this for templates as well, in dotnet/core-sdk):

$ find /usr/share/dotnet/
/usr/share/dotnet/
/usr/share/dotnet/templates
/usr/share/dotnet/templates/3.0.0
/usr/share/dotnet/packs
/usr/share/dotnet/packs/NETStandard.Library.Ref
/usr/share/dotnet/packs/NETStandard.Library.Ref/2.1.0
/usr/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref
/usr/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/ref/netstandard2.1
/usr/share/dotnet/packs/NETStandard.Library.Ref/2.1.0/data
/usr/share/dotnet/packs/Microsoft.NETCore.App.Host.linux-x64
/usr/share/dotnet/packs/Microsoft.NETCore.App.Host.linux-x64/3.0.0
/usr/share/dotnet/packs/Microsoft.NETCore.App.Host.linux-x64/3.0.0/runtimes
/usr/share/dotnet/packs/Microsoft.NETCore.App.Host.linux-x64/3.0.0/runtimes/linux-x64
/usr/share/dotnet/packs/Microsoft.NETCore.App.Host.linux-x64/3.0.0/runtimes/linux-x64/native
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/ref
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/ref/netcoreapp3.0
/usr/share/dotnet/packs/Microsoft.NETCore.App.Ref/3.0.0/data

[dagood]

I found this doc about guidelines that I think is quite useful for packs ownership: https://fedoraproject.org/wiki/PackagingDrafts/Revised_File_and_Directory_Ownership

When I look at the packs dir, what I'm thinking first is if it's reasonable to add a dependency from the targeting packs to something that owns the packs dir. The targeting pack RPMs don't currently have any dependencies, and there are no packages in core-setup that I think make sense to own the packs dir since it is only relevant for SDK installs.

I think having all packs co-own the directories is the way to go, "The directory is owned by a package which is not required for your package to function."

A virtual package for the "SDK filesystem" is an alternative, but it would make the set of RPM packages diverge from the set of Debian packages so I don't see it as a great option.

I believe the packs also need to co-own dotnet, or else that would still be an unowned directory. (For example, someone may have the .NET Core SDK in ~ but want to use the distro-provided targeting packs. If dotnet isn't owned, that dir would stick around after uninstalling the targeting packs.)