Replies: 6 comments 22 replies
-
The closest thing we have for this today is https://github.com/dotnet/designs/blob/main/accepted/2020/reproducible-builds.md . The basic idea is that the PDB of the binary in nuget package contains list of sources and compiler command line used to build the package that should be enough to allow re-creating the binary.
How is this done for Java or Python? We should be able to follow the same plan. |
Beta Was this translation helpful? Give feedback.
-
|
Java is probably closest to .NET. The Java guidelines for packaging things in Fedora, for example, live here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ To answer the specific parts:
Python guidelines are here: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/ |
Beta Was this translation helpful? Give feedback.
-
|
I like this general idea. It's a question of how to achieve it. While the reproducible builds are a good suggestion, it's definitely not productized and unlikely to be successful w/o cooperation from the library owner. I propose some complementary ideas:
I'll be the first to admit that this is hand-wavy. Also, for such a system to work, there needs to be circular influence/feedback. This has the potential to be a big lift. Folks would need to really want this for it to work, including distros, app authors, and library authors. Certainly, it could work. |
Beta Was this translation helpful? Give feedback.
-
|
@richlander We might be saying the same thing. Basically, if we took a look at the packages on NuGet, which ones are likely to be interesting to our partners, and what are their qualities? For instance, Newtonsoft.Json is interesting because it's an extremely common dependency in the .NET ecosystem. It contains multiple TFMs. |
Beta Was this translation helpful? Give feedback.
-
|
Removing frameworks and RIDs can change the behavior of the package so it's not always "safe" to do. Back in the 1.0 days we had a switch that let source-build have "partial" packages where any removed configurations were replaced with placeholders - so that it would break the build rather than give someone the "wrong" asset. For example - imagine removing the Technically it's not hard to build for different TFMs in source-build, it's just additional work. We can represent the TFMs with reference packs and the tools used to build them are purely managed. RIDS on the other hand are a different story since the managed components can (and do today) build on any platform, but the native assets require platform specific toolchains. So "worst case" I think we just overbuild the managed side. I think the "best case" here is we standardize the entire stack on LatestTFM + netstandard2.0 - then we can remove all the other TFMs and not worry about behavior changes as a result. For RIDs we can also drop the assets specific to the RIDs we aren't building - similarly keeping in mind the heirarchy -- for example we might want to keep both It'd be nice if we could do this without forcing everyone to adopt changes to their projects. @ViktorHofer might have some ideas since this is similar to tricks we play in the runtime's TargetFramework SDK. |
Beta Was this translation helpful? Give feedback.
-
|
@ericstj That's interesting insight. Any idea what happened with the placeholder approach? |
Beta Was this translation helpful? Give feedback.
-
|
I believe it worked well enough, but over time we found so much of the product relied on building for so many different frameworks that we eventually just turned most of the build back on. |
Beta Was this translation helpful? Give feedback.
-
|
RIDs will require special care from the package maintainer as the native assets will either need to be source-build, or the managed library will need to be built so it uses the system provided libraries (for example: make |
Beta Was this translation helpful? Give feedback.
-
@omajid what is the difference is with that issue? Can we keep a single issue? |
Beta Was this translation helpful? Give feedback.
-
|
I think dotnet/core#7443 is a subset. That issue that talks only about building applications from source/offline. That's a large chunk of this issue, but I wanted to capture the rest of the things that need to be done to onboard .NET applications into linux distros as well. I am happy to merge this (though I don't know how to) if you think that we should only have one place tracking everything. |
Beta Was this translation helpful? Give feedback.
-
|
For me, the MVP here looks like:
The sources and build script can then be used by a package maintainer to package up the app further. |
Beta Was this translation helpful? Give feedback.
-
|
That's a good MVP. As @jkotas suggested, we could use the PDB for that purpose. That seems kinda hard and also very indirect to me. It requires restoring the dependencies of the whole app first and then inspecting the PDBs in the nupkgs. Instead, it would be ideal if there was a top-level list of packages w/a link to the source repo. It occurs to me that Central Package Management is super close to what we want. If we can add a https://devblogs.microsoft.com/nuget/introducing-central-package-management/ |
Beta Was this translation helpful? Give feedback.
-
|
Each nupkg should have a reference to its source repo, ref, and maybe other metadata that describes how the package got built (e.g. .NET project path in the repo). These sources will need to be downloaded for all dependencies, and the distro package maintainer will include them in the 'src package' that corresponds to the 'app package' he/she is building. It's important to have the local sources resemble the upstream source repositories to facilitate patching. The Central Package Management could be used to switch from using 'binary' packages from nuget.org to packages built from source locally. |
Beta Was this translation helpful? Give feedback.
-
|
Has best practice evolved on this? I packaged powershell for Alpine Linux a year ago, and the newer versions now include more dependencies that are not trivial to build from source. An issue was opened with the upstream team: PowerShell/PowerShell#20143 but indeed I'm not sure how to proceed. |
Beta Was this translation helpful? Give feedback.
-
|
We're also running into this with trying to bring Jellyfin into Fedora (rhbz#2238840). It'd be great to see some progress on this front. cc: @mooninite |
Beta Was this translation helpful? Give feedback.
-
|
I mentioned in the last .NET security partners meeting that I am investigating how to solve this issue for Ubuntu. @omajid wrote me an email if I can share ideas or strategies. I thought to answer here in case someone else is interested/want's to provide feedback. I do not yet have a final solution for this problem. There are still open questions. I tried to organize my random collection of notes and thoughts here: OverviewMy broad idea/plan is to:
Note To avoid false expectations. There is no official commitment from Canonical that we actually do that! Rudimentary NuGet packages we already builtIn Ubuntu we have the package Currently, the Ubuntu package contains a tarball, which contains the NuGet packages and is installed at For example, here is the content of the latest .NET 9 tarball ( Some of these NuGet packages could be packaged into deb packages. It would also probably make sense to bundle a few of these NuGet packages into Where to place the NuGet packageWhere do we place the According to this documentation In this config file we can specify where we want to install the packages to.
Some of these locations could be used by future .NET versions, so we should An example config file could look like this: <?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="System Packages" value="/usr/lib/dotnet/system-packages" />
</packageSources>
</configuration>See this documentation Patching solution scoped NuGet config filesThere are many projects that have a NuGet config files at the .NET solution file <packageSources>
<clear />
<!-- approved sources by the project -->
</packageSources>This aims to solve the "It works on my machine" problem where the developers of Solution I can see here is
Limited functionalityA local package source limits the functionality of the NuGet client compared to For example, the following command will fail, because the NuGet client can not We have to add the available local version: Maybe we could write a daemon that provides the v3 nuget protocol as a local nuget server via HTTP. Providing runtime dependenciesLet's assume we have solved all the issues how to build the .NET app. This opens up a new question: What do we do with these dependencies? 1. Embed them in the deb packageEmbedding the dependencies in the deb package is probably the easiest option. BUT it is not really optimal. Every time there is an update to one of the 2. Setup symbolic linksWe could put the dlls in a known location and simply create symbolics of them 3. Use the runtime package storeThere exists a feature in the .NET SDK/runtime that is pretty mush what we want. It allows us to store the dll files in a single place and tell the runtime to The documentation suggest placing this store at Additionally we can specify a manifest when publishing a .NET app and the SDK A minimal example workflow to use this would be: We do not need to use the dotnet store command. We can simply put the dll's in the correct location. Here is an example of a store folder structure: Where do we get the dll's from?Note This section is purely about the dll's of the .NET source built artifacts. Getting the NuGet packages was easy, but getting the dll's is a little bit more
Self-contained apps
I would not recommend to build self-contained .NET apps when packaging them for a distro.
Challenges with packaging runtime NuGet packagesNote This section is a bit deb packaging specific, but you may have similar issues I spent a bit of time looking into how to package the runtime NuGet packages, e.g.
They need to be built on a specific architecture and os, but could be used on There is no way that we can get the binaries from e.g. 22.04. There simply does Can we get the runtime packages of another architecture. There are 2 options: package the runtime packages as architecture independent packages (
|
Beta Was this translation helpful? Give feedback.
-
To avoid having to make a system config setting, you can set some build props/environment variables during the package build like
Yes, it makes sense to decide on a location where .nupkg are installed from where they can be used as build dependencies. This location is meant for source-building distro packages. It is not meant to be a default location for distro end-users. The packages in this location may deviate from upstream packages (like support less target frameworks, have content removed due to license restrictions, ...).
The simplest option is to provide the application as published. That is also what the upstream project is doing. I wouldn't try to deviate unless you are sure it solves a real problem.
I don't know why
I think this depends on the app and it is at the package maintainer's discretion. If you are building a small command-line tool you may prefer to have something that is NativeAOT and trimmed.
I am not familiar with Ubuntu packaging: is there a need to be able to cross-compile to packaged .NET apps? If a package can be built natively on the architecture, is that not enough? As I mentioned in an earlier comment, I think the real challenge in packaging .NET apps is in handling the source code of dependencies. |
Beta Was this translation helpful? Give feedback.
-
I totally agree that the primary purpose should be to enable source-building distro packages, but I would be delighted if some developers use the distro packages as a third-party NuGet package sources. For example, in my experience it is not uncommon to use the python distro packages instead of pip on Ubuntu. To be fair, this is only possible, because there are so many maintained python packages. I should have probably made this clearer in my post that this is one motivation for me.
That would work too. Thanks for mentioning I also looked into this to make it also usable for end-users.
There is no need to be able to cross-compile. Currently, I think that Additionally this plays into making it usable for end-users. As an end-user I can also download packages like Bonus: This could reduce build resource utilization: assuming a maintainer wants to build a self-contained .NET app; they may build it for all architectures from one architecture instead of dispatching multiple build jobs. Of course there are many cases where you need to build on the target architecture.
I wanted to express that by default we should not build self-contained .NET apps. It is common in distro packaging that certain defaults get applied, which deviate from the build properties of the upstream project. If there are significant performance benefits than the maintainers can always overwrite/disable the defaults. This is a tradeoff between:
There is also a difference between the kind of package upgrades an end-user would experience, but this is very dependent on the situation:
Please correct me if I understood it wrong: You want to get all the sources of all dependencies and then build them together with the .NET app we want to build. This sounds similar to go packaging. (note: I am not a go developer, so I hope that I got this comparison right). From a deb packaging perspective, this sounds like a lot of extra packaging work with limitations. This is effectively static linking (with all it's consequences for maintainers) and does not allow (or at least makes it incredibility hard) to share dependencies. See for example: https://wiki.debian.org/StaticLinking#Go I want to share dependencies in Ubuntu and not rebuild them every time they are used. I don't know much about rpm packaging and RHEL/Fedora policies/recommendations. Is static linking much more common/preferred? From the .NET build process perspective: This sounds incredibly hard to accomplish. Many .NET projects I have encountered have their own unique workflow how the artifacts get build and expectations for the build environment. Even the file layout of the repos are often different. Simply dumping the source code of all dependencies next to the app we want to build is not enough. A more concise version of what I want to do is:
|
Beta Was this translation helpful? Give feedback.
-
We prefer dynamic linking too, but there might be more areas where people have realized that trying to get rid of static linking is like trying to boil the ocean and given up. For example, https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/ says "You can provide a package that uses nodejs, but you should bundle all the nodejs libraries that are needed". |
Beta Was this translation helpful? Give feedback.
-
I think package maintainers want to have a .NET app packaged with the least amount of work on their end. Dealing with these binary dependencies represents the bulk of the work. It's tedious, and it adds no value. Rather than push this to package maintainers, I'd like the .NET tooling to be able to get the sources. Unfortunately, I don't think the use-case is sufficiently important for upstream .NET to invest. Anyway. You have some options, and as you try them you'll find out which work better. |
Beta Was this translation helpful? Give feedback.
-
A number of Linux distributions (and other OSs) are now using and packaging .NET (via source-build) into their distributions. With .NET available in the distro, users are looking to build on top of it. For example, someone was recently looking for guidance on how to package https://github.com/GitCredentialManager/git-credential-manager into Fedora. That led to some conversation in a Fedora context that I think is general enough that it would apply to most other distros as well.
You can see the original discussion here: https://pagure.io/packaging-committee/issue/1193.
I talked about this with @crummel who suggested starting a discussion here.
Before digging into specific, is this - packaging software built on top of .NET into distros - something we want to encourage and support?
If so, there's quite a few challenges that we need to solve. The challenges are similar to what we encounter in source-build: we need to build everything from source without access to the internet. Here's what I see as the big ones:
Newtonsoft.Jsonwould be used by a huge percentage of .NET applications, it seems like it would fit in best with the distro policies if we packaged it up once and then applications or higher-level libraries could use that without having to maintain or build this code.Newtonsoft.Json, we would need to find a way to rebuild everything that consumesNewtonsoft.Json. Is there a way for an application to use a dynamic-linking ordlopen-style orLoadLibrary-style approach to load the packaged copy ofNewtonsoft.Json.dll?.nupkg,.dllfiles that are meant to be used by other applications? Where should standalone applications live? (This can only be a very rough recommendation, because every distro has its own policies on paths and install locations).This is also related to dotnet/core#7443
cc @dotnet/distro-maintainers @leecow @richlander @tmds
Beta Was this translation helpful? Give feedback.
All reactions