Hey, Neal Gompa <[email protected]> writes:
> On Mon, Dec 1, 2025 at 11:47 AM Michael Cronenworth <[email protected]> wrote: >> >> Hi all, >> >> Has anyone dealt with or have suggestions for a package that bundles about >> 1950 >> packages from various sources and programming languages? >> >> The package in question is "Jellyfin" that is currently in review[1]. A list >> of >> bundled packages is attached to the review bug. In order to adhere to >> packaging >> guidelines and list bundled packages I would need to add about 1950 lines to >> the >> spec file. I would also need a way to get licensing data from these as well. >> Is >> plowing ahead the only option? >> > > Since it's a .NET application, perhaps the DotNet SIG might have some > ideas on what to do here. Omair, what do you think? I don't have a solution, sorry. In fact, I think the amount of work has been underestimated. Taking a step back: .NET is similar to Java in terms of how dependencies work. .NET applications or libraries have dependencies on other *binary* .NET libraries. Like Java, there's no standard/automated way to bundle the dependency sources. And like Java, there's no way to go through an entire dependency graph and build everything from source. This is unlike npm/javascript where the dependencies can be tracked as sources, and packagers can bundle the sources and build everything together. So, even if we deal with all the license/listing issues that have been flagged in the thread so far, I can't see a way to build this package in Fedora while complying with the "no binaries" policy. Last time we discussed this upstream, we made some progress but the conclusion generally was that the "no binaries" policy of distributions like Fedora mean that building dependency libraries from source is simply too much work and there's not enough motivation/justification in the ecosystem to make the changes that would be needed to solve this. https://github.com/dotnet/source-build/discussions/2960 On a more positive note, I skimmed the list of bundled(dotnet*) dependencies in the list, and I think it might be possible to make it quite a bit shorter. I see lots of duplication in versions of dependencies being used, such as this set: bundled(dotnet-system.collections.immutable) = 7.0.0 bundled(dotnet-system.collections.immutable) = 8.0.0 bundled(dotnet-system.collections.immutable) = 9.0.0 These versions match with .NET versions. This feels like jellyfin is being compiled against multiple versions of .NET so it can run against any of those versions. We might be able to make a hard decision that jellyfin should only support the latest (as an example) and then go from 3 dependencies to just 1. Some dependencies like dotnet-runtime.ubuntu.16.10-x64.runtime.native.system.security.cryptography.openssl are part of the .NET runtime (and so already packaged in Fedora). In fact, I think all the bundled(dotnet-runtime-*) dependencies can be ignored (though we might have to tweak the jellyfin build system?) Probably the same applies to many of the bundled(dotnet-system*) dependencies. Confusingly, sometimes they are provided by the SDK (and so don't need to be tracked, built or bundled) but sometimes not. We might be able to ignore test dependencies (eg, xunit, coverlet, coverage) and assume/rely on upstream already having tested it, and remove those from our bundled list. Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
