CLR package guidelines

This document defines the standard for packaging Common Language Runtime (.NET) projects under Arch Linux. Currently only Mono is capable of providing a usable, efficient CLR runtime for multiple systems and this standard will reflect its use. Be aware that a lot of CLR programs were developed with Microsoft .NET in mind and, as such, may or may not run under Mono because of .NET-exclusive factors such as P/Invoke calls and Microsoft digital rights management (DRM) APIs and are thus will not yield a usable package for Arch Linux. However, if combined with Wine as of version 1.5.6 (?), your package may have a chance to run under it. Please see the Wine PKGBUILD Guidelines for more information if such is the case.

Arch package guidelines

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – VCS – Web – Wine

Packaging gotchas
  • Always add mono to depends
  • Always set arch to any. Mono does not yet support compiling (running?) 64-bit assemblies.
  • Always add !strip to options
  • If the package is a library (DLL), consider installing it to Mono's global assembly cache (GAC) if it is to be used as a dependency.
  • If the assembly is precompiled and comes with a program debug database file (Foo.dll.pdb), consider converting it as such: pdb2mdb Foo.dll
  • If the package is meant to be executed (EXE), be sure to install to /usr/bin a shell script to run it, similar to this one:
#!/bin/sh
mono foo.exe "$@"

Signed assemblies

If the package is to be installed into the GAC, be sure it has a signed key file. If not, you can generate one like this: sn -k 1024 Foo.snk. Following that, the easiest way to embed the key file into the assembly is to disassemble it like this: . Afterwards, reassemble it like so:

Sample PKGBUILDs

The following examples will try to cover some of the most common conventions and build systems.

gollark: Ah, but if your kiosk is in an untrusted environment you can *still* view the code on it in a disk drive.
gollark: You can just prevent terminating if we don't allow (somehow) disk-MitM-y attacks.
gollark: What do you mean?
gollark: If your kiosks are in trusted environments you can just stick whatever code you want on them and nobody can look at them *anyway*, but we're assuming they're not. I think.
gollark: Okay, yes, if you don't control the kiosk's code or hardware all you can do is snoop on network traffic.
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.