Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 916661 - dev-dotnet/dotnet-sdk use architecture-independent source tarball
Summary: dev-dotnet/dotnet-sdk use architecture-independent source tarball
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: dotnet project
Depends on:
Reported: 2023-11-01 17:21 UTC by Esteve Varela Colominas
Modified: 2024-03-20 23:39 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Esteve Varela Colominas 2023-11-01 17:21:39 UTC
Let me preface this by saying I'm really glad that dotnet-sdk is finally a thing in ::gentoo. I was working on getting it packaged back when it was 5.0, but eventually gave up given the long compile times and frequent variability of the package.

One of the things I put a lot of work towards was making sure that at least the base SDK would be possible to rebuild without any architecture-dependent binaries or tarballs in SRC_URI. You may find my work at [1]. Essentially, it's following the standard fedora set in terms of generating a source tarball, and then stripping it of its binaries (or see my script at [2]). Instead, USE=-system-bootstrap would download a (pinned, as low as possible) binary version of the SDK separately, to bootstrap using that.

The idea being that in the long run, we'd be able to have a bootstrap process akin to dev-lang/rust, where you have the option of using bootstrap binaries, or bootstrapping from rust-bin. This would make porting the ebuild to more architectures more convenient as well, I feel.

Other than that, a lot of work went into making sure CFLAGS were passed along through the various layers of the build system properly, a patch was added to opt out of telemetry, and it was ensured that the package would build with LTO. Maybe some of that work is still useful, but I'd have to check.

Comment 1 Esteve Varela Colominas 2023-11-01 17:25:33 UTC
I should note that this issue is partially also a reminder for myself to tackle this whenever I have time. I've never liked how the dotnet ecosystem relies on prebuilt binaries for everything, I wonder how dotnet-runtime-nugets relates to my old dotnet-reference-packages.
Comment 2 Maciej Barć gentoo-dev 2023-11-01 18:59:45 UTC
All of that would probably have to be redone, since there were very big changes from 5 to 7 and big changes from 7 to 8.


I think the best would be to work on cutting .NET SDK to pieces like the page shows: and then thinking about bootstrap, optimization and all other good stuff.

It absolutely impossible to do this in one person and a team of AT LEAST TWO if not more people who have extensive knowledge about .NET and Gentoo is needed to set this up properly.  

At this time I just play safe and cracks in our current handling of .NET start to show, see:

Also it does not help that .NET upstream (cough Microsoft, cough) prioritizes Windows, changes their build system every Friday and DELETES BOOTSTRAP BINARIES! Last time I tried to build NEW .NET SDK 7.0.402 (I think) it failed fetching bootstrap exes.
Comment 3 Esteve Varela Colominas 2023-11-01 22:23:36 UTC
Yeah, I expected the changes to be big while dotnet has a fun time trying to solidify. Thankfully, the work with regards to building an arch-independent source tarball has largely already been done for us by fedora:
This is what I started off of when making the scripts and ebuild linked in the OP.

re: rant
Microsoft's guidelines in terms of distribution packaging are aimed at binary distributions that can get away with splitting build outputs over several packages. I think they're largely not applicable to gentoo and will be more trouble than they're worth in the long run, but it's worth evaluating.
I'd be willing to help out with some of this, but I'm currently heavily bottlenecked by how long it takes to build these packages.