mirror of
https://github.com/quamotion/dotnet-packaging.git
synced 2026-02-16 13:55:09 +00:00
RPM packaging doesn't flag .NET Core DLLs as executables #34
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @clemensv on GitHub (Jul 6, 2018).
In docker images where the package manage configuration suppresses the installation of documentation files (e.g. tsflags=nodocs in dnf.conf), any .NET DLLs are not installed when using package managers that observe such configuration.
The RPM packaging logic only considers ELF files as being executables (.NET Core DLLs are PE files), and non-executables are generally being packaged as documentation files, meaning the default install behavior is that everything except ELF binaries is not being installed, including none of the .NET assemblies, but also none of the other included non-ELF files, which will not at all be documentation.
Because that's not even overridable in higher-level package management utilities like yum on the command line, this ends up being a hard blocker for correct RPM packaging.
My suggestion for fixing this is to switch to an alternate strategy where documentation files are explicitly flagged as such.
@qmfrederik commented on GitHub (Jul 6, 2018):
Thx for the feedback; I'm travelling this & next week so I'll be a bit slow to respond.
@clemensv commented on GitHub (Jul 8, 2018):
Sent email.
@clemensv commented on GitHub (Aug 11, 2018):
I've spent some time looking at that code path and trying to figure out how to fix this.
What I see in the code is quite a bit of effort that tries to have the output of this packager match the shape of an arbitrary existing RPM package (libplist) for test purposes. For instance, all non-ELF files seem to get packaged as doc files because that's how the test against libplist can be satisfied and not because they're truly classified as doc. That decision just goes by file system flag.
I've done some work to classify .NET assemblies correctly (classified as "mono" in RPM), adapted the file color model, and dropped the blanket doc classification in my fork so far, but without further surgery in the classification model (which may include project hints on what is a doc file and what's not) I'm not going to make the current tests pass.
See here
ebc9045169@qmfrederik commented on GitHub (Aug 13, 2018):
You are correct that the most unit tests use the libplist package as a reference package. It is indeed an arbitrary choice.
When doing the first implementation of dotnet-rpm, I found the RPM file format to be very finicky (some RPM packages failing to install because of differences which seem arbitrary), so I went for "full binary compatibility".
This can probably be weakened, if there are sufficient tests in the CI process to guarantee that we don't regress and are suddenly creating RPM packages which fail to install on some versions of CentOS/RedHat.
A better way to satisfy that goal may be to actually try to install the RPM packages dotnet-rpm generates on RedHat/CentOS. I guess this should be doable with a Linux-based CI system (say, Travis) and use Docker to test the generated packages on various versions or RedHat/CentOS.
For the file colors in particular, there's at least one unit test (
RpmPackageCreatorTests.CreateFiles) which tries to generate a RPM package for .NET projects and tries to make sure the file colors are correct.There are two implementations of the FileAnalyzer classes -
PlistFileAnalyzerandDotnetFileAnalyzerwhich try to get the file colors right in different scenarios.IIRC, the RPM utility itself uses the
filecommand to determine the file colors, we can try to mimic that.@clemensv commented on GitHub (Aug 13, 2018):
As you'll see in the related PR, a likely reason for your unit tests struggling with the roundtripping is that you've so far not read the metadata of the RPM file to reconstruct the ArchiveEntry data. You treat the CPIO stream as if it were a file directory just as if you are constructing the package "going forward" from the project system, but without looking at the metadata you don't have the same level of metadata hints as you have in the project system, so it's not much of a surprise that it's troublesome to get the project output package and the re-read package content to match up.
@clemensv commented on GitHub (Aug 13, 2018):
Regarding the tests: In the project where I'm using the packager, I set up a MSBuild integrated, Docker-based verification test, see here. The build/test/clean stages are all scripts that get triggered from the .proj. I think that's easy to adapt for here.
Here I would make the container with the plain base image in the build step, and then run the install of a generated package with a subsequent verification script that everything is indeed in place as expected as the test.
The reference package might be generated as a dependency in a MSBuild task from a different directory also during the build step.
@qmfrederik commented on GitHub (Aug 31, 2018):
@clemensv I've implemented a slightly different approach in #74 which seems to fix the issue.
With this change, I can now install & run projects packaged with
dotnet rpmon docker images based on CentOS, Fedora, Oracle Linux,... .Hope it helps!