[WIP] New package: dotnet-6.0.100

[TinfoilSubmarine]

Testing the changes

• I tested the changes in this PR: briefly

New package

• This new package conforms to the quality requirements: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-glibc
• [WIP] I built this PR locally for these architectures (if supported. mark crossbuilds):

Supersedes #27170. I followed the packaging guidelines in the source-build repo. I aligned with the recommended packages list here minus dotnet-runtime-deps.

[ci skip]

[rmboggs]

If it helps, I have been using this new package on my machine without issues so far. Unfortunately, I haven't tested with musl, however.

[TinfoilSubmarine]

Also wanted to mention that this bootstraps from a prebuilt dotnet-sdk since (surprise surprise) Roslyn, the .NET compiler, is self-hosting. I'm hoping this is OK since I did some poking around Void documentation and didn't see anything about bootstrapping from prebuilts.

[TinfoilSubmarine]

There is some discussion here about a full source bootstrap, but it never went anywhere: dotnet/source-build#1930

[TinfoilSubmarine]

I am working on building on x86_64-musl currently. I am having some issues with part of the build though, I'll post the log here later.

I already had to add an additional dependency (gettext-devel) for musl to build, and it also incorrectly detects the RID as linux-x64 instead of linux-musl-x64 unless /etc/os-release is present, so I added runit-void as well, which is a bit hack-y. I've already detailed the issue in dotnet/source-build#2459.

One thing that I need to understand is the architectures this should target. Currently if you pass /p:Platform="${_foreign_architecture}" to build.sh it downloads an Ubuntu (or Alpine) rootfs for the target architecture and runs under QEMU, which doesn't seem to be acceptable, especially since some of the tooling needed (qemu-debootstrap to name one) to facilitate this isn't available in void-packages currently. I've added nocross=yes to the template, but theoretically this should still be buildable as long as the target arch is the same as the host arch. Is this something we can do with e.g. a new build_helper like build_helper=qemu, or should this just be left as nocross=yes?

[TinfoilSubmarine]

Log as mentioned above.
msbuild.log

[Anachron]

imo dotnet is such a beast, it's okay to mark it nocross for now and give it another try later.

[TinfoilSubmarine]

I agree with marking nocross.

However, I'm trying to determine if this will build on other archs than x86_64 right now. I'm letting my Rpi3 (so aarch64) give it the ol' college try, but it's taking a while and hanging on some weird things...

[rmboggs]

This may not be the best option but would it be possible to consider just making this x86_64 glib only for now while musl and arm64 are worked on? Just a thought.

[TinfoilSubmarine]

So I haven't been able to make any progress on getting this working on musl or other architectures. I've updated the template to be x86_64 only for now, and the PR is ready for review.

[rmboggs]

@TinfoilSubmarine,

Thank you for adding this to the template:

vmkdir etc/dotnet
echo '/usr/lib/dotnet' > "${DESTDIR}"/etc/dotnet/install_location

I've confirmed I can get EntityFrameworkCore (using PostgreSQL) working when the above entry in the template is installed in the system. :)

Any ETA of when this can be pulled into the package tree?

[rmboggs]

I went through this and it looks good. Also, I have actually been using this package extensively for over a week now with no issues. Would be great to get this in.

[rmboggs]

Any word on when this could possibly go in?

Also, version 6 is expected to be released next month. Will this package just be updated to 6 or will this require additional steps to ensure nothing breaks during the upgrade?

[TinfoilSubmarine]

I'll have to rebase on 6 once the source-build repo gets support for it. I'll dig around and see if they are expecting to support it soon.

[TinfoilSubmarine]

So I need some help understanding how to make this bootstrap-able. Currently the template will build from a pre-built SDK every time. How would I go about using the previously built version of dotnet to build the next version, seeing as the build-system always uses the latest version causing a cyclic dependency in this case?

[jcgruenhage]

One thing you could do for bootstrapping this is having a virtual package that depends on the newest version, and having a package per version similar to how the linux<x.y> packages work. I've thought about a similar approach for rust, but so far rust is binary bootstrapped and that's apparently not a problem, so I guess having binary bootstrapped dotnet would also be fine.

[TinfoilSubmarine]

Closing as I no longer have a use for this. I did recently push a working dotnet6 template which is available here if anyone wants to take another shot at this. It is likely very difficult; the work going on to get this packaged for Alpine should give some appreciation for the difficulty of this.

[ayakael]

I'm the package maintainer for Alpine's dotnet packaging project. If anyone should want some advice or some notes, feel free to mention me in whatever space that you're working in. I wouldn't wish working on this from scratch for anyone - source-build has a lot of moving parts, which makes it a major PITA. For anything I work on, I like to document my problems as much as possible for future use. Thus, there's a devlog on Alpine's package MR dotnet31 / 5 and 6 available below. It goes in more nuts and bolts of packaging for Alpine, while the Github threads are more dotnet specific.

31: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28197
5: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28195
6: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29253

[astralchan]

I'm the package maintainer for Alpine's dotnet packaging project. If anyone should want some advice or some notes, feel free to mention me in whatever space that you're working in. I wouldn't wish working on this from scratch for anyone - source-build has a lot of moving parts, which makes it a major PITA. For anything I work on, I like to document my problems as much as possible for future use. Thus, there's a devlog on Alpine's package MR dotnet31 / 5 and 6 available below. It goes in more nuts and bolts of packaging for Alpine, while the Github threads are more dotnet specific.

31: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28197 5: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28195 6: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29253

How to build dotnet6 stack

• Build testing/dotnet6-stage0 (provides prebuilt bits for first bootstrap bld)

Is it not possible to build completely from source? Are these prebuilts available for crossbuild and musl?

[ayakael]

I'm the package maintainer for Alpine's dotnet packaging project. If anyone should want some advice or some notes, feel free to mention me in whatever space that you're working in. I wouldn't wish working on this from scratch for anyone - source-build has a lot of moving parts, which makes it a major PITA. For anything I work on, I like to document my problems as much as possible for future use. Thus, there's a devlog on Alpine's package MR dotnet31 / 5 and 6 available below. It goes in more nuts and bolts of packaging for Alpine, while the Github threads are more dotnet specific.
31: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28197 5: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28195 6: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/29253

How to build dotnet6 stack

• Build testing/dotnet6-stage0 (provides prebuilt bits for first bootstrap bld)

Is it not possible to build completely from source? Are these prebuilts available for crossbuild and musl?

It is possible to build dotnet entirely from source, but as dotnet builds upon itsel, you need a bootstrap dotnet compiler. Microsoft provides linux-musl prebuilts for armv7, aarch64, x86_64 which dotnetx-stage0 fetches and packages. As it is policy for Alpine Linux to not allow binaries immediately built by prebuilt binaries, dotnetx-bootstrap sources dotnetx-stage0 to build an Alpine version of a bootstrap SDK. dotnetx-bootstrap is then sourced by dotnetx-build, which builds the bits that are going to be packaged for availability to end-user. As Alpine does not support versioning for subpackages, and as runtime and sdk have two different versioning schemes, but share the same build process, the actual packaging of artifacts from dotnetx-build is done by dotnetx-sdk and dotnetx-runtime.

I encourage anyone to study the APKBUILD file, which reads very much like a shell script. I have made sure to leave ample comments and documentation for those interested in porting to other package managers.

[ayakael]

The most important one is testing/dotnet6-build/APKBUILD as that shows the necessary steps to build with linux-musl. All patches include comments on why they are necessary, what errors they fix, etc. For packaging guidelines, I highly recommend following this page. Of note, dotnet needs two things to build from scratch: a prebuilt dotnet SDK, and source-built nupkgs which are provided by Private.SourceBuild.Artifacts.tar.gz which contains arch-agnostic bits and linux-x64 bits. As linux-musl-{x86_64,aarch64,armv7} is targetted on Alpine, dotnetx-stage0 goes beyond packaging the SDK and prebuilt artifacts: it also replaces all linux-x64 nupkgs with linux-musl-$arch nupkgs. (edit: dotnet also builds its own Private.SourceBuild.Artifacts.tar.gz, thus the Microsoft versions are only used by dotnetx-bootstrap)

I highly recommend ya'll open up an issue at dotnet/installer. The developpers there have been of great help.

[mjeveritt]

Any chance of revisiting this? It would be kinda cool to get back to #27787 also ..

I don't think I can handle the dotnet package as a void newbie, but I can probably get the Pinta one going ..

[astralchan]

Any chance of revisiting this? It would be kinda cool to get back to #27787 also ..

I don't think I can handle the dotnet package as a void newbie, but I can probably get the Pinta one going ..

That PR is abandoned. Feel free to pick it up, but I am no longer interested in maintaining a pinta package. For the sake of the tracker, consider that PR abandoned.

[mjeveritt]

Any chance of revisiting this? It would be kinda cool to get back to #27787 also ..
I don't think I can handle the dotnet package as a void newbie, but I can probably get the Pinta one going ..

That PR is abandoned. Feel free to pick it up, but I am no longer interested in maintaining a pinta package. For the sake of the tracker, consider that PR abandoned.

WFM .. at this point, stalled on the dotnet, as here .. afaict it's never moved forward .. the pinta section I Suspect I can handle .. not like we're dealing with, like, electron here .. chuckle

[ayakael]

Of note, first release candidate of dotnet7 on Alpine Linux is implemented here: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/39122

[rmboggs]

No promises but I'll try to pick this up again in a couple of weeks when I get back home. IIRC, the main hurdle right now is getting to to build/run on musl. I'll setup a musl machine when I get back home now that they have new images to use.

I know that dotnet 7.0 will probably be released by that time so there will be more work to do on this but there is already a good starting point so hopefully it won't be too bad to get it up to speed. And hopefully, we can get someone to fully approve it this time. ;)

[ayakael]

hurdle

I'm in the processus of getting a bunch of patches for dotnet6 and dotnet7 pushed to upstream, so hopefully by 6.0.111 the processus will be easier for ya'll. We just got dotnet6 on s390x working, although they are still some hurdles.

You can follow the state of backporting in dotnet/source-build#3087.

The difference between dotnet6 and dotnet7 in terms of build procedure isn't big, so going from one to the next shouldn't take much work.

[ayakael]

A few changes since February:

• redid dotnet6-stage0 as to allow crossbuild to new platforms, and now it only builds the minimum components to build dotnet, acting as a shim between Microsoft provided builds and Alpine Linux.
  This is especially relevant for linux-musl nupkgs, as they are not included in Private.SourceBuild.Artifacts.tar.gz. stage0 thus takes the already prebuilt linux-musl SDKs, builds the musl specific nupkgs while rebuilding the SDK for use by dotnet6-build.
• Removed custom functions on dotnet6-build as to simplify the process. Most relevant to ya'll: all patches are now rebased to the tarball. It should be copy paste for ya'll.

Good luck! For dotnet7 we were to target release with Alpine 3.17, but there's so little time between release of 3.17 and 7 that I think I'll target 3.18. The final package should come a bit later, as s390x and ppc64le are both platforms that are still a bit broken for dotnet7.

[mjeveritt]

<snip>

Good luck! For dotnet7 we were to target release with Alpine 3.17, but there's so little time between release of 3.17 and 7 that I think I'll target 3.18. The final package should come a bit later, as s390x and ppc64le are both platforms that are still a bit broken for dotnet7.

That all sounds very promising .. getting cross-platform code going is good for portability, making cross-libc coding that much easier to complete!

[ayakael]

Check out this then. Since dotnet is actually an ecosytem of components packaged together, to figure out crosscompilation it was necessary to identify the core-components to build. Our stage0 package thus builds the following components:

• runtime (this is where the actual crosscompilation happens, as clang builds the c# runtime)
• roslyn (we then build roslyn compilers using the current bootstrap sdk. As it's all c# code, the corssbuilt sdk will be able to run the code)
• sdk (takes runtime, roslyn, and downloads prebuilt c# code and packages initial SDK code)
• aspnetcore (using roslyn, and other downloadable prebuilt c# code, packages aspnetcore runtime)
• installer (using runtime, sdk, and aspnetcore artifacts, packages an SDK tarball similar to what upstream provides)

The idea is that we just need to feed the tarball SDK to stage0 on the target platform, and it'll build from scratch and package in a .apk file the necessary bootstrap artifacts for use by dotnet6-build.

dotnet6-build can then take those packaged artifacts, feeds them into source-build, and builds the whole stack properly so that no upstream prebuilts are used. Now that dotnet6-build is built, future builds will use build rather than stage0 to build itself.

I don't know how void does its crossbuilding. Alpine crossbuilds via sysroots so our stage0 is built around that.

[rmboggs]

So, update. With a little fine tuning, I was able to get dotnet 7 installed on my current Void setup and it is currently working as expected with the limited testing I was able to do. I want to do more testing before I start working on the musl side, then submit it to this repo.

I do have a small concern with this. I noticed that when it installs, it only installs the version 7 targeting pack. I am unable to build projects that target dotnet 6. Since 7 just came out, most, if not all, projects will need to be adjusted and tested to run on 7 before running. Based on this, I'm wondering if 6 still needs to be included. If so, what's the best way to approach this?

Lastly, should we take this conversation somewhere else, like Discord or someplace? Feels kinda weird to report progress on a closed pull request.

Thoughts?

Thanks,
Ryan

[jcgruenhage]

You could open a new pull request and report progress there if that's better? Would have the benefit that you can push your changes there so people can give feedback on that early.

As for a chat: Void uses IRC for chat. Topics around packaging stuff is handled in the #xbps channel on libera.chat. If you're looking to access that in a way that's more similar to Discord, I'd recommend using Matrix: https://matrix.to/#/#xbps:libera.chat

[rmboggs]

You could open a new pull request and report progress there if that's better? Would have the benefit that you can push your changes there so people can give feedback on that early.

That's what I was planning on doing since it's a new version. I was more worried about the discussions around it.

As for a chat: Void uses IRC for chat. Topics around packaging stuff is handled in the #xbps channel on libera.chat. If you're looking to access that in a way that's more similar to Discord, I'd recommend using Matrix: https://matrix.to/#/#xbps:libera.chat

Ok, I'll check out matrix first. If I don't like it, I'll check the IRC.

Thanks,
Ryan

[ayakael]

FWIW, Alpine ships both .NET 6 and .NET 7 until either are EOL for this very reason. .NET 6 being an LTS, many projects wont update till .NET 8 is out.

[rmboggs]

FWIW, Alpine ships both .NET 6 and .NET 7 until either are EOL for this very reason. .NET 6 being an LTS, many projects wont update till .NET 8 is out.

Yeah, I am thinking that should be the way to go. I just don't know the best approach for this. Should I just make separate packages for each version (ex: dotnet6, dotnet7, etc)? Should i just make a regular and lts packages? Thoughts?

Thanks,
Ryan

[ayakael]

FWIW, Alpine ships both .NET 6 and .NET 7 until either are EOL for this very reason. .NET 6 being an LTS, many projects wont update till .NET 8 is out.

Yeah, I am thinking that should be the way to go. I just don't know the best approach for this. Should I just make separate packages for each version (ex: dotnet6, dotnet7, etc)? Should i just make a regular and lts packages? Thoughts?

Thanks, Ryan

We do the former (i.e. dotnet6, dotnet7). Indeed, they are times when 3 versions are supported once (like right now with .NET3.1 .NET 6 and .NET 7). As NET is designed to allow multiple versions to be installed at once, it's the right way to go. The distribution guidelines have been especially useful to us, although rather than name ours dotnet-sdk-6.0 we went for dotnet6-sdk.

[ayakael]

@rmboggs Where are y'all moving the conversation? My changes sometimes only check for Alpine, so if y'all hit issues, they are likely issues that I've already fixed but not for void. Also, how do y'all differentiate musl and non-musl void? Does the RID change? I can imagine that being problematic.

[JamiKettunen]

Also, how do y'all differentiate musl and non-musl void? Does the RID change? I can imagine that being problematic.

@ayakael XBPS_TARGET_LIBC global variable can be used in the build templates (there's also XBPS_LIBC for the host one), sometimes also XBPS_TARGET_MACHINE (or XBPS_MACHINE) are used which can have a -musl suffix or none for glibc.

[rmboggs]

@ayakael ,
I haven't moved the convo over yet because I still need to do some things first (such as re organizing the package names, testing musl, etc.).

Speaking of which, if I need to add musl specific patches to the packages, what it the best way to do that? Are there flags or special names to use for the patch files? Please let me know.

[rmboggs]

For those interested, I opened a new issue here to continue this conversation. I'm still fine-tuning dotnet7 and begun updating the dotnet6 template (originally started by @TinfoilSubmarine) so it references the latest version of the 6.0 branch.

[rmboggs]

Dotnet 6: Repo
Dotnet 7: Repo
Continued discussion here, for those who want toe help out with this.