|
|
# Maintaining Spack on Adélie Linux
|
|
|
|
|
|
[Spack](https://git.adelielinux.org/adelie/spack) is a (mostly) self-contained source-based distribution for scientific and high-performance computing (HPC).
|
|
|
|
|
|
We maintain a fork so that we can bring musl to these communities and catch portability/correctness bugs in many software packages where correctness and performance are a top priority.
|
|
|
|
|
|
This document was originally located in an `APKBUILD` file; please maintain the comments and formatting.
|
|
|
|
|
|
```
|
|
|
# rev. 2022-11-07
|
|
|
#
|
|
|
# principles
|
|
|
# ----------
|
|
|
#
|
|
|
# * Upstream creates "release" branches, e.g. 'releases/v0.18'
|
|
|
# and only backports important fixes to these branches. They
|
|
|
# periodically tag these changes as X.Y.Z "point" releases.
|
|
|
#
|
|
|
# https://github.com/spack/spack/tree/develop#releases
|
|
|
#
|
|
|
# All Spack releases are considered "stable"; each release
|
|
|
# branch freezes (with some exceptions) the packages.
|
|
|
#
|
|
|
# We want to track 'develop' so we can have accurate patches
|
|
|
# for both Spack itself and for upstream packages, and to be
|
|
|
# able to test quickly. We are helping to develop Spack, so
|
|
|
# to reduce round-trip latency, we must absorb some churn.
|
|
|
#
|
|
|
# * Our 'develop' branch mirrors the upstream 'develop' branch
|
|
|
# which has all the package churn and updates you'd expect.
|
|
|
#
|
|
|
# * Some software will fail to build/test because it does not
|
|
|
# run on architectures we care about, or work with musl. We
|
|
|
# are going to track these issues and try to upstream these
|
|
|
# patches all the way to the original upstream, if possible.
|
|
|
#
|
|
|
# * If an issue was first found to affect packages.git, then a
|
|
|
# new issue should be created there, otherwise at spack.git.
|
|
|
# If the issue was reported by a user, it should probably be
|
|
|
# in the correct place already. (Folks who use Spack know if
|
|
|
# the package they're having issues with is Spack-provided).
|
|
|
#
|
|
|
# * Our 'adelie' branch is always based on 'develop' and holds
|
|
|
# our patches intended for upstreaming. It is OK to force
|
|
|
# push to this branch if based correctly, but please have a
|
|
|
# trusted maintainer review your branch or merge request.
|
|
|
#
|
|
|
# * It is important to distinguish between patches that should
|
|
|
# go to their original upstreams vs. patches specific to our
|
|
|
# distribution. The latter are considered "local" patches,
|
|
|
# and should reside in our 'user/spack' directory.
|
|
|
#
|
|
|
# * Patches that should be upstreamed, whether to fix Spack or
|
|
|
# fix an upstream package, are considered "upstreamable" and
|
|
|
# are to be maintained in the 'adelie' branch.
|
|
|
#
|
|
|
# * For issues whose fixes should be upstreamed, add the group
|
|
|
# label 'UPSTREAM', regardless of which project owns it. Do
|
|
|
# not apply this label for anything that should go directly
|
|
|
# to Spack; that is implied by being in the 'adelie' branch
|
|
|
# of our Spack fork, except in one specific case.
|
|
|
#
|
|
|
# The exception is if Spack rejects such a patch, in which
|
|
|
# case we will move the patch to 'user/spack' to be "local",
|
|
|
# remove the 'UPSTREAM' label, and replace it with 'LOCAL',
|
|
|
# and close the issue (since it has been patched locally).
|
|
|
#
|
|
|
#
|
|
|
# etiquette
|
|
|
# ---------
|
|
|
#
|
|
|
# * We may have found needed patches elsewhere online, or we
|
|
|
# may have created them ourselves. This is IMPORTANT!
|
|
|
#
|
|
|
# If a patch is not compatible with, or is unavailable under
|
|
|
# BOTH the MIT and Apache-2.0 licenses, but IS available at
|
|
|
# a reliable remote URL, then our patch for Spack would use
|
|
|
# their URL-specified patching mechanism, which downloads it
|
|
|
# at the time the package is built/installed by users.
|
|
|
#
|
|
|
# In all other cases, patches should be included in-tree.
|
|
|
# Spack policy is "dealer's choice" if the URL is reliable,
|
|
|
# but there is no compelling reason to prefer that method.
|
|
|
#
|
|
|
# * DO NOT rewrite history older than, or equal to, any tags!
|
|
|
#
|
|
|
# Our patches are intended to go upstream and be maintained
|
|
|
# by the corresponding maintainer(s), i.e. they bump their
|
|
|
# stuff and we don't have to chase & rebase.
|
|
|
#
|
|
|
# * "Ideally" (to quote Spack maintainers), anyone who updates
|
|
|
# a Spack-provided package should check whether the patches
|
|
|
# are still needed, rebase them as needed, and carry them
|
|
|
# forward. In reality, this doesn't always happen, so if a
|
|
|
# fix is merged upstream AND Spack bumps its package AND we
|
|
|
# release our own Spack package containing all that, relevant
|
|
|
# issues and merge requests should have 'UPSTREAM' removed.
|
|
|
#
|
|
|
# * Unfortunately, we may have patches for those same packages
|
|
|
# in our packages tree, which Spack CANNOT consume directly.
|
|
|
#
|
|
|
# Therefore, we may be in a position of duplicating some of
|
|
|
# the patches. In the event that an upstream fix is applied,
|
|
|
# we should be able to update packages.git fairly quickly.
|
|
|
#
|
|
|
# The likelihood of "local" patches needing to be duplicated
|
|
|
# is very low; Spack is intended to be self-contained. When
|
|
|
# would this happen? Perhaps if 'gcc' is configured special.
|
|
|
#
|
|
|
#
|
|
|
# maintenance
|
|
|
# -----------
|
|
|
#
|
|
|
# * The below steps assume you are work in 'adelie/spack.git',
|
|
|
# have checked out the 'adelie' branch, and want to bump the
|
|
|
# APKBUILD for 'user/spack' for a new release to users.
|
|
|
#
|
|
|
# * Upstream always tags versions for release. When preparing
|
|
|
# to update our APKBUILD, choose a point in 'adelie' that is
|
|
|
# tested for all architectures. We will consider this to be
|
|
|
# "stable" modulo commits not found in the release branch.
|
|
|
#
|
|
|
# Note that our patches MUST be based on branch 'develop'.
|
|
|
# Spack backports fixes to release branches; by definition
|
|
|
# these are included in 'develop' if they are needed.
|
|
|
#
|
|
|
# * Find the nearest upstream release tag. Run './maintain' to
|
|
|
# to see this information; the script is a convenience.
|
|
|
#
|
|
|
# * Create a branch, e.g. 'git branch adelie-vX.Y.Z adelie',
|
|
|
# so that X.Y.Z is the nearest upstream point release.
|
|
|
#
|
|
|
# * We will NOT continue to rebase patches in this branch. The
|
|
|
# act of creating this branch is, for us, cutting a release.
|
|
|
#
|
|
|
# * If additional patches are needed, they go in 'develop' and
|
|
|
# can be backported to the newly-created branch for p2, p3,
|
|
|
# and beyond. This way, we can choose to cherry-pick from
|
|
|
# 'develop', or work on our own release branches. Please be
|
|
|
# careful when referring to commit hashes in commit messages
|
|
|
# as the act of rebasing the 'adelie' branch may mess it up.
|
|
|
#
|
|
|
# * Where does _pN fit in? This is a tag. Tag 'adelie-vX.Y.Z',
|
|
|
# initially, as 'adelie-vX.Y.Z_p1'. Next time that branch
|
|
|
# has been updated and you wish to send it to users, create
|
|
|
# another tag and update the APKBUILD accordingly.
|
|
|
#
|
|
|
``` |
|
|
\ No newline at end of file |