aae50af089
- Separate the agreement into its own paragraph to provide a clear overview for potential new maintainers - Remove some redundancies and rephrase parts of the agreement - Make links in README.md relative |
||
|---|---|---|
| automated | ||
| stackage | ||
| Stackage | ||
| .dir-locals.el | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| .project-settings.yml | ||
| .travis.yml | ||
| build-constraints.yaml | ||
| check | ||
| CURATORS.md | ||
| DATA-FLOW.md | ||
| debian-bootstrap.sh | ||
| Dockerfile | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| README.md | ||
stackage
"Stable Hackage": creating a vetted set of packages from Hackage. This repository is for package authors and maintainers to get their packages into Stackage. If you simply want to use Stackage as an end user, please follow the instructions on https://www.stackage.org/.
We strongly recommend using the Haskell tool stack for doing builds, which
has Stackage support built-in: stack 
.
Add your package
We welcome all packages, given that
- they are compatible with current snapshots (roughly speaking: work with the latest released versions of GHC and of all the package's dependencies);
- there is a maintainer willing to promise to keep it that way.
See the maintainers agreement for more details.
Other repos
The Stackage project consists of multiple repositories. This repository contains the metadata on packages to be included in future builds and some project information. In addition, we have the following repositories:
We also support some add-on tools to cabal-install to make its usage with Stackage both easier and more secure:
Curious how it all fits together? See the Stackage data flow.
Build the package set
Generally only the stackage build server run by the stackage curator team and people intrested in incorporating stackage snapshots into an OS distribution need to build the entire package set. If you're interested in trying this yourself, please check out the curator guide, though be aware that this is not a recommended practice and there likely will be problems you will need to debug yourself.
Processing
The following describes at a high level the series of steps for processing
Nightlies
- Get list of core packages
- Get build constraints from list of maintained packages
- Load up package index
- Calculate build plan using newest versions of packages
- Write out a YAML file with complete build plan
- Verify that the build plan can be compiled
- Perform the build
LTS
- Load up most recent build plan
- Convert build plan into constraints for next build
- Continue from step (3) above