- Adds pijul as type
- explicit dot is the same as root
- Update doc/cabal-package-description-file.rst
- Grammar, comma required for non-restrictive clause
- Move warning down the section
- Move repository stuff to its own page
- Add author and consumer subsections
- Keep consistent ordering
- Put source-repository before source-repository-package
- Reword intro and add hackage linking
- A field of this type is always optional
- Fix typo
- Put the table into the field types section
- Link to VCS kind, consistent casing
- Introduce the VCS acronym early
- Link to cabal get for this|head
- Update doc/cabal-package-description-file.rst
- Comma after as an example
- Update doc/cabal-package-description-file.rst
- There are two kinds comma
- Split sentences.
- Move to how to section
- Add version control fields
- Rewrite package consumer section
- Bump source packages up a level
- Rename as "how to source packages"
- Rename section, "package source"
- Fix whitespace
- Mention manual download before cabal download
- Use a description list for source-repository fields
- Add a warning about the confusing field names
- Clarify *source code* ``.tar.gz`` archive
- Use Git uppercase
- Source Marker section, marks out
- Change to "inside a single VCS repository"
- Taking a Dependency from a Source Code Repository
- Lead with uppercase first letter for Darcs, Git
- Fix whitespace
- Use lowercase for titles
- Change the guide title to "How to get package *source code*".
- Hackage is for published, exact versus range of versions
- Mention cabal get
- Lead with uppercase for Cabal and Hackage
- Move VCS fields up in the tree
- Mention *source code* in all the section titles
- Explain how linking helps contributors and maintainers
- Add an example of conversion
- Add a dependency vendoring section
- Show cloning with cabal build --dry-run
- Keep VCS fields small
- Add diagrams
- Warn about hash in clone folder name
- Use code style for .cabal
- Use lower caps in title to match other sections
- Add missing _ for external link reference
- Move package authoring section to last
- Use subsections for vendoring
- Add a section about publishing
- Fix up anchors and references
- Typo, "extracts it to a directory"
- It is a "``cabal get`` unpacking step"
- Use a comma in "Fork, don't vendor"
- Add a tag to the src-repo-pkg example
- The warning about commits is only for Git repositories
- Move note to setting up section
- Fix whitespace
- Missing source-repository ead in the diff
- Use with/without a "-package" suffix ... belongs
- Add a reference to cabal get
- How to locate and get
- Add back the ref to the package consumer section
- Replace arrowheads with ASCII
- Replace ticked checkboxes with ASCII
- Warn about project and the set of pkgs separately
- Multiple dependency packages not multiple dependencies
- Shorter explanation of vendoring
- Lower caps for bold terms
- Add references to VCS fields
- A marker that points to
- Use the shorter "shepherd"
- Use grab (not obtain) before obtaining
- Clarify terms in source code note
- Hackage is only for published package dependencies
- Add a link to hackage upload
- Add a footnote about packages of a cabal.project
- Revert section title to "Specifying the local packages"
- Change shepherd to "deal with"
- Put source after package, ordering how to guides
- Comma after as

Co-Authored-By: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-Authored-By: brandon s allbery kf8nh <allbery.b@gmail.com>

The goal is for users to easier find pages for typical problems through search engines and page navigation.
- The top-level layout is based on the popular documentation structure by https://documentation.divio.com/ to give a
   clear structure to users and future documentation contributors:
  * Guides: Present a solution to a single, atomic, typical user problem.
  * Reference: Describe user API (CLI fields, syntax etc) with technical rigour and completeness.
  * Explanation: Discuss background information, scope, design decisions etc.
- Move existing documentation roughly into these categories with minimal editing as the basis for further editing.
- Rename guide titles to mention how-to for improving SEO.
- Rename some files to improve SEO since that name becomes part of the URL (often called slug).
  Important page keywords should appear in the slug as well to make pages rank higher in search engines.

Fix #2349 and #7825

There was nothing about installing packages in this file for a while now.

[ci skip]

Note all Described instances are implemented. This is just a start.

quasicomputational authored 6 years ago and Herbert Valerio Riedel committed 6 years ago

As suggested in #5401.

[skip ci]

This is the result of using `pandoc` with default settings
to convert the existing `.markdown` files to `.rst` files.

Needed because cabal-install no longer compiles against Cabal-1.23.1 snapshot
that came with GHC 8.

While reading the docs, I saw a few typos, so I ran ispell through the
docs. Fixed:

- plain typos
- a few instances of 'ie'→'i.e.' and 'eg' → 'e.g.' for nicer style
- a few capitalisation issues (linux, unix)
- a few not-nice (IMHO) abbreviations (for a manual, that is):
  distro→distribution, repo→repository
- proper naming (RedHat→Red Hat)

Fixes #1686.

Currently we have a somewhat hard-to-maintain contents just in the
introduction. This cuts that initial contents down to just link to
the chapters (plus sections within the intro), and then use an
automatically generated table of contents in the other chapters.

Also tweak the CSS because pandoc's TOC feature turns all section
headings into links and that changes the visual appearance. Use the
CSS to make it look the same as before.

Introduce cabal-install much earlier. Give more of a basic intro.

Fixes #1113.

Makes things a little simpler in GHC's build system if libraries are in
the same directory as their name.

At the top level we now have cabal/ and cabal-install/

The chapter on installing packages still needs to be rewritten
to describe the cabal tool, rather than runhaskell Setup.hs