dotnet for Debian

    Packaging .Net 6 on Ubuntu
    ==========================

    We don't have a public place for getting the orig tarball before it is released on MSFT side (obviously),
    so now in our watch file we provide a way to check when a new version is available but it will not
    produce the tarball (in the future, the code may be stored publicy one it's released by MSFT, 
    and then that address will be in the watch file).


    To recreate tarball and source code for building the package, the steps are
    the following:

    * Get the latest code from https://launchpad.net/ubuntu/+source/dotnet6 with `pull-lp-source dotnet6` 
    * Change the watch file to use the correct address:
      +  for private repo if you're building on embargo time: add the private repo after the script.
      +  on public released time: switch between the comments and change the repo part to a on our side.
    * `uscan`
    
    Now, a `dotnet6_6.0.10X.orig.tar.xz` tarball file has been generated with a new folder 
    for the next version in the parent folder (the actual folder remains the same), so do a
    `cd ../dotnet6-6.0.10X`.
    
    _
    - 2. If you want to build the package directly:
      * mv dotnet6 `dotnet6-6.0.106`

    Whichever method you choose before, you should now have a folder called `dotnet6-6.0.10X` 
    and in its parent directory a file called `dotnet6_6.0.10X.orig.tar.xz`.

    Please, check that you have installed `sbuild` and `debhelper` on your system. Also, a
    schroot for kinetic  is needed (you can create it with
    `sudo sbuild-createchroot --arch=amd64 kinetic /var/lib/schroot/chroot/kinetic-amd64  http://archive.ubuntu.com/ubuntu/`).

    Now, we use the following command for the building (you can use `DEB_BUILD_OPTIONS="parallel=n"`
    on front of the command, changing n to the number of parallel 
    process you can dedicate to it if any):

    * `sbuild -d kinetic --arch=amd64 --purge-build=successful --debbuildopts='--buildinfo-option=-O' --build-dir=..`
    

    We already would have the prebuilds binaries packaged  needed for bootstraping in a deb file
    (dotnet-sdk-6.0-source-built-artifacts*.deb).
    

    Some context
    ============

    Depending on the time you're building the package (embargoed or no) you need to use 
    a different git repo to recreate the tarball.

    Requirements for building
    =========================

    Locally: For the above timing, I use DEB_BUILD_OPTIONS="parallel=16" in
    front of the sbuild command (my machine has 64 MB RAM and an AMD 9 Ryzen
    5000 series processor). The space needed is ~50 GB (including the generated
    .deb files in parent directory. Build log file is ~125MB). To install the
    debs in a VM, I used to create it with 30GB of disk space.

    PPA: It's necessary to ask to increase disk space to at least to 10GB

    Now, the package is prepared to be build using sbuild, without the
    need of extract the source tarball.

    Packaging Desing considerations
    ===============================

    *Using alternatives*

    One of the requirements for dotnet was to allow multiple SDKs (major versions)
    installed at the same time on a machine. For that reason, we are using update-alternatives
    for implementing it.

    The path would be /usr/lib/dotnet/dotnet6 and this would be a simlink (via /etc/alternatives)
    to /usr/lib/dotnet/dotnet-6.0.105 (e.g., in the case of SDK v6.0.105).

    As the dotnet-host is the package that contains the binary dotnet cli, these operations are
    being made around it. The items that has to be conducted by the alternatives are:

    * The binary.
    * The bash completion script for that binary
    * The man pages of that binary.
    * The configuration files (install_location) that points to a concrete SDK.

    For that reason, .manpages , .bash-completions or .dirs files are not being used (as they need to
    be set before update-alternatives comes to play). Therefore, some of these are being done manually
    in the overriding install section of the rules files, as well as the generation of the 
    .update-alternatives file (on-the-fly).

    *Lintian Overrides*

    * license-problem-non-free-RFC: Every folder under src includes a THIRD_PARTY_NOTICES.TXT file 
      (that triggers the error). Also the file
      src/runtime.*/src/coreclr/utilcode/guidfromname.cpp is multilicensed.

    * source-is-missing: We have three cases here for overriding this:
      - 1. JS files: It looks like these are all false-positives.
           The *.js files all contain the full source code  and license headers.
           Also, there are *.min.js files available; these would be a problem if
           they were not accompanied by the corresponding *.js, but that doesn't
           seem to be the case here.
      - 2. HTML files: Also a false positive due to the use of the substring ".Link"
           in their names.
      - 3. prebuilds from MS Arcade: This files are needed for boostrapping the first
           release of the package (they will disappear in upcoming releases).



     -- Miriam España Acebal <miriam.espana@canonical.com>  Tue, 21 Jul 2022
     12:58:49 +0200
