[Pkg-haskell-commits] darcs: haskell-cabal: New upstream release
KAction at gnu.org
KAction at gnu.org
Sun Mar 15 11:22:02 UTC 2015
Sun Mar 15 11:18:27 UTC 2015 KAction at gnu.org
* New upstream release
R ./docs-sources/Cabal.css
R ./docs-sources/developing-packages.markdown
R ./docs-sources/index.markdown
R ./docs-sources/installing-packages.markdown
R ./docs-sources/misc.markdown
R ./docs-sources/
M ./changelog +6
M ./control -2 +2
R ./patches/quickcheck-2.7.patch
R ./patches/series
R ./patches/
M ./changelog +2
Sun Mar 15 11:18:27 UTC 2015 KAction at gnu.org
* New upstream release
diff -rN -u old-haskell-cabal/changelog new-haskell-cabal/changelog
--- old-haskell-cabal/changelog 2015-03-15 11:22:02.209827033 +0000
+++ new-haskell-cabal/changelog 2015-03-15 11:22:02.213827032 +0000
@@ -1,3 +1,11 @@
+haskell-cabal (1.22.1.1-1) UNRELEASED; urgency=medium
+
+ * New upstream version
+ * Remove doc-sources (now distributed by upstream)
+ * Remove quickcheck patch (fixed upstream)
+
+ -- Dmitry Bogatov <KAction at gnu.org> Sun, 15 Mar 2015 13:49:03 +0300
+
haskell-cabal (1.20.0.2-2) experimental; urgency=medium
* Depend on haskell-devscripts 0.9, found in experimental
diff -rN -u old-haskell-cabal/control new-haskell-cabal/control
--- old-haskell-cabal/control 2015-03-15 11:22:02.209827033 +0000
+++ new-haskell-cabal/control 2015-03-15 11:22:02.213827032 +0000
@@ -2,14 +2,14 @@
Section: haskell
Priority: extra
Maintainer: Debian Haskell Group <pkg-haskell-maintainers at lists.alioth.debian.org>
-Uploaders: Joachim Breitner <nomeata at debian.org>
+Uploaders: Joachim Breitner <nomeata at debian.org>, Dmitry Bogatov <KAction at gnu.org>
Build-Depends: debhelper (>= 9)
, cdbs
, haskell-devscripts (>= 0.9)
, ghc
, ghc-prof
Build-Depends-Indep: ghc-doc
-Standards-Version: 3.9.2
+Standards-Version: 3.9.6
Homepage: http://hackage.haskell.org/package/Cabal
Vcs-Darcs: http://darcs.debian.org/pkg-haskell/haskell-cabal
Vcs-Browser: http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/haskell-cabal
diff -rN -u old-haskell-cabal/docs-sources/Cabal.css new-haskell-cabal/docs-sources/Cabal.css
--- old-haskell-cabal/docs-sources/Cabal.css 2015-03-15 11:22:02.213827032 +0000
+++ new-haskell-cabal/docs-sources/Cabal.css 1970-01-01 00:00:00.000000000 +0000
@@ -1,49 +0,0 @@
-body {
- max-width: 18cm;
-}
-
-div {
- font-family: sans-serif;
- color: black;
- background: white
-}
-
-h1, h2, h3, h4, h5, h6, p.title { color: #005A9C }
-
-h1 { font: 170% sans-serif }
-h2 { font: 140% sans-serif }
-h3 { font: 120% sans-serif }
-h4 { font: bold 100% sans-serif }
-h5 { font: italic 100% sans-serif }
-h6 { font: small-caps 100% sans-serif }
-
-pre {
- font-family: monospace;
- border-width: 1px;
- border-style: solid;
- padding: 0.3em
-}
-
-pre.screen { color: #006400 }
-pre.programlisting { color: maroon }
-
-div.example {
- margin: 1ex 0em;
- border: solid #412e25 1px;
- padding: 0ex 0.4em
-}
-
-div.example, div.example-contents {
- background-color: #fffcf5
-}
-
-a:link { color: #0000C8 }
-a:hover { background: #FFFFA8 }
-a:active { color: #D00000 }
-a:visited { color: #680098 }
-
-h1 a:link, h2 a:link, h3 a:link, h4 a:link, h5 a:link, h6 a:link,
-h1 a:visited, h2 a:visited, h3 a:visited, h4 a:visited, h5 a:visited, h6 a:visited {
- color: #005A9C;
- text-decoration: none
-}
diff -rN -u old-haskell-cabal/docs-sources/developing-packages.markdown new-haskell-cabal/docs-sources/developing-packages.markdown
--- old-haskell-cabal/docs-sources/developing-packages.markdown 2015-03-15 11:22:02.209827033 +0000
+++ new-haskell-cabal/docs-sources/developing-packages.markdown 1970-01-01 00:00:00.000000000 +0000
@@ -1,2122 +0,0 @@
-% Cabal User Guide: Developing Cabal packages
-
-
-# Quickstart #
-
-
-Lets assume we have created a project directory and already have a
-Haskell module or two.
-
-Every project needs a name, we'll call this example "proglet".
-
-~~~~~~~~~~~
-$ cd proglet/
-$ ls
-Proglet.hs
-~~~~~~~~~~~
-
-It is assumed that (apart from external dependencies) all the files that
-make up a package live under a common project root directory. This
-simple example has all the project files in one directory, but most
-packages will use one or more subdirectories.
-
-To turn this into a Cabal package we need two extra files in the
-project's root directory:
-
- * `proglet.cabal`: containing package metadata and build information.
-
- * `Setup.hs`: usually containing a few standardized lines of code, but
- can be customized if necessary.
-
-We can create both files manually or we can use `cabal init` to create
-them for us.
-
-### Using "cabal init" ###
-
-The `cabal init` command is interactive. It asks us a number of
-questions starting with the package name and version.
-
-~~~~~~~~~~
-$ cabal init
-Package name [default "proglet"]?
-Package version [default "0.1"]?
-...
-~~~~~~~~~~
-
-It also asks questions about various other bits of package metadata. For
-a package that you never intend to distribute to others, these fields can
-be left blank.
-
-One of the important questions is whether the package contains a library
-or an executable. Libraries are collections of Haskell modules that can
-be re-used by other Haskell libraries and programs, while executables
-are standalone programs.
-
-~~~~~~~~~~
-What does the package build:
- 1) Library
- 2) Executable
-Your choice?
-~~~~~~~~~~
-
-For the moment these are the only choices. For more complex packages
-(e.g. a library and multiple executables or test suites) the `.cabal`
-file can be edited afterwards.
-
-Finally, `cabal init` creates the initial `proglet.cabal` and `Setup.hs`
-files, and depending on your choice of license, a `LICENSE` file as well.
-
-~~~~~~~~~~
-Generating LICENSE...
-Generating Setup.hs...
-Generating proglet.cabal...
-
-You may want to edit the .cabal file and add a Description field.
-~~~~~~~~~~
-
-As this stage the `proglet.cabal` is not quite complete and before you
-are able to build the package you will need to edit the file and add
-some build information about the library or executable.
-
-### Editing the .cabal file ###
-
-Load up the `.cabal` file in a text editor. The first part of the
-`.cabal` file has the package metadata and towards the end of the file
-you will find the `executable` or `library` section.
-
-You will see that the fields that have yet to be filled in are commented
-out. Cabal files use "`--`" Haskell-style comment syntax. (Note that
-comments are only allowed on lines on their own. Trailing comments on
-other lines are not allowed because they could be confused with program
-options.)
-
-If you selected earlier to create a library package then your `.cabal`
-file will have a section that looks like this:
-
-~~~~~~~~~~~~~~~~~
-library
- exposed-modules: Proglet
- -- other-modules:
- -- build-depends:
-~~~~~~~~~~~~~~~~~
-
-Alternatively, if you selected an executable then there will be a
-section like:
-
-~~~~~~~~~~~~~~~~~
-executable proglet
- -- main-is:
- -- other-modules:
- -- build-depends:
-~~~~~~~~~~~~~~~~~
-
-The build information fields listed (but commented out) are just the few
-most important and common fields. There are many others that are covered
-later in this chapter.
-
-Most of the build information fields are the same between libraries and
-executables. The difference is that libraries have a number of "exposed"
-modules that make up the public interface of the library, while
-executables have a file containing a `Main` module.
-
-The name of a library always matches the name of the package, so it is
-not specified in the library section. Executables often follow the name
-of the package too, but this is not required and the name is given
-explicitly.
-
-### Modules included in the package ###
-
-For a library, `cabal init` looks in the project directory for files
-that look like Haskell modules and adds all the modules to the
-`exposed-modules` field. For modules that do not form part of your
-package's public interface, you can move those modules to the
-`other-modules` field. Either way, all modules in the library need to be
-listed.
-
-For an executable, `cabal init` does not try to guess which file
-contains your program's `Main` module. You will need to fill in the
-`main-is` field with the file name of your program's `Main` module
-(including `.hs` or `.lhs` extension). Other modules included in the
-executable should be listed in the `other-modules` field.
-
-### Modules imported from other packages ###
-
-While your library or executable may include a number of modules, it
-almost certainly also imports a number of external modules from the
-standard libraries or other pre-packaged libraries. (These other
-libraries are of course just Cabal packages that contain a library.)
-
-You have to list all of the library packages that your library or
-executable imports modules from. Or to put it another way: you have to
-list all the other packages that your package depends on.
-
-For example, suppose the example `Proglet` module imports the module
-`Data.Map`. The `Data.Map` module comes from the `containers` package,
-so we must list it:
-
-~~~~~~~~~~~~~~~~~
-library
- exposed-modules: Proglet
- other-modules:
- build-depends: containers, base == 4.*
-~~~~~~~~~~~~~~~~~
-
-In addition, almost every package also depends on the `base` library
-package because it exports the standard `Prelude` module plus other
-basic modules like `Data.List`.
-
-You will notice that we have listed `base == 4.*`. This gives a
-constraint on the version of the base package that our package will work
-with. The most common kinds of constraints are:
-
- * `pkgname >= n`
- * `pkgname >= n && < m`
- * `pkgname == n.*`
-
-The last is just shorthand, for example `base == 4.*` means exactly the
-same thing as `base >= 4 && < 5`.
-
-### Building the package ###
-
-For simple packages that's it! We can now try configuring and building
-the package:
-
-~~~~~~~~~~~~~~~~
-cabal configure
-cabal build
-~~~~~~~~~~~~~~~~
-
-Assuming those two steps worked then you can also install the package:
-
-~~~~~~~~~~~~~~~~
-cabal install
-~~~~~~~~~~~~~~~~
-
-For libraries this makes them available for use in GHCi or to be used by
-other packages. For executables it installs the program so that you can
-run it (though you may first need to adjust your system's `$PATH`).
-
-### Next steps ###
-
-What we have covered so far should be enough for very simple packages
-that you use on your own system.
-
-The next few sections cover more details needed for more complex
-packages and details needed for distributing packages to other people.
-
-The previous chapter covers building and installing packages -- your own
-packages or ones developed by other people.
-
-
-# Package concepts #
-
-Before diving into the details of writing packages it helps to
-understand a bit about packages in the Haskell world and the particular
-approach that Cabal takes.
-
-### The point of packages ###
-
-Packages are a mechanism for organising and distributing code. Packages
-are particularly suited for "programming in the large", that is building
-big systems by using and re-using code written by different people at
-different times.
-
-People organise code into packages based on functionality and
-dependencies. Social factors are also important: most packages have a
-single author, or a relatively small team of authors.
-
-Packages are also used for distribution: the idea is that a package can
-be created in one place and be moved to a different computer and be
-usable in that different environment. There are a surprising number of
-details that have to be got right for this to work, and a good package
-system helps to simply this process and make it reliable.
-
-Packages come in two main flavours: libraries of reusable code, and
-complete programs. Libraries present a code interface, an API, while
-programs can be run directly. In the Haskell world, library packages
-expose a set of Haskell modules as their public interface. Cabal
-packages can contain a library or executables or both.
-
-Some programming languages have packages as a builtin language concept.
-For example in Java, a package provides a local namespace for types and
-other definitions. In the Haskell world, packages are not a part of the
-language itself. Haskell programs consist of a number of modules, and
-packages just provide a way to partition the modules into sets of
-related functionality. Thus the choice of module names in Haskell is
-still important, even when using packages.
-
-### Package names and versions ###
-
-All packages have a name, e.g. "HUnit". Package names are assumed to be
-unique. Cabal package names can use letters, numbers and hyphens, but
-not spaces. The namespace for Cabal packages is flat, not hierarchical.
-
-Packages also have a version, e.g "1.1". This matches the typical way in
-which packages are developed. Strictly speaking, each version of a
-package is independent, but usually they are very similar. Cabal package
-versions follow the conventional numeric style, consisting of a sequence
-of digits such as "1.0.1" or "2.0". There are a range of common
-conventions for "versioning" packages, that is giving some meaning to
-the version number in terms of changes in the package. Section [TODO]
-has some tips on package versioning.
-
-The combination of package name and version is called the _package ID_
-and is written with a hyphen to separate the name and version, e.g.
-"HUnit-1.1".
-
-For Cabal packages, the combination of the package name and version
-_uniquely_ identifies each package. Or to put it another way: two
-packages with the same name and version are considered to _be_ the same.
-
-Strictly speaking, the package ID only identifies each Cabal _source_
-package; the same Cabal source package can be configured and built in
-different ways. There is a separate installed package ID that uniquely
-identifies each installed package instance. Most of the time however,
-users need not be aware of this detail.
-
-### Kinds of package: Cabal vs GHC vs system ###
-
-It can be slightly confusing at first because there are various
-different notions of package floating around. Fortunately the details
-are not very complicated.
-
-Cabal packages
-: Cabal packages are really source packages. That is they contain
- Haskell (and sometimes C) source code.
-
- Cabal packages can be compiled to produce GHC packages. They can
- also be translated into operating system packages.
-
-GHC packages
-: This is GHC's view on packages. GHC only cares about library
- packages, not executables. Library packages have to be registered
- with GHC for them to be available in GHCi or to be used when
- compiling other programs or packages.
-
- The low-level tool `ghc-pkg` is used to register GHC packages and to
- get information on what packages are currently registered.
-
- You never need to make GHC packages manually. When you build and
- install a Cabal package containing a library then it gets registered
- with GHC automatically.
-
- Haskell implementations other than GHC have essentially the same
- concept of registered packages. For the most part, Cabal hides the
- slight differences.
-
-Operating system packages
-: On operating systems like Linux and Mac OS X, the system has a
- specific notion of a package and there are tools for installing and
- managing packages.
-
- The Cabal package format is designed to allow Cabal packages to be
- translated, mostly-automatically, into operating system packages.
- They are usually translated 1:1, that is a single Cabal package
- becomes a single system package.
-
- It is also possible to make Windows installers from Cabal packages,
- though this is typically done for a program together with all of its
- library dependencies, rather than packaging each library separately.
-
-
-### Unit of distribution ###
-
-The Cabal package is the unit of distribution. What this means is that
-each Cabal package can be distributed on its own in source or binary
-form. Of course there may dependencies between packages, but there is
-usually a degree of flexibility in which versions of packages can work
-together so distributing them independently makes sense.
-
-It is perhaps easiest to see what being ``the unit of distribution''
-means by contrast to an alternative approach. Many projects are made up
-of several interdependent packages and during development these might
-all be kept under one common directory tree and be built and tested
-together. When it comes to distribution however, rather than
-distributing them all together in a single tarball, it is required that
-they each be distributed independently in their own tarballs.
-
-Cabal's approach is to say that if you can specify a dependency on a
-package then that package should be able to be distributed
-independently. Or to put it the other way round, if you want to
-distribute it as a single unit, then it should be a single package.
-
-
-### Explicit dependencies and automatic package management ###
-
-Cabal takes the approach that all packages dependencies are specified
-explicitly and specified in a declarative way. The point is to enable
-automatic package management. This means tools like `cabal` can resolve
-dependencies and install a package plus all of its dependencies
-automatically. Alternatively, it is possible to mechanically (or mostly
-mechanically) translate Cabal packages into system packages and let the
-system package managager install dependencies automatically.
-
-It is important to track dependencies accurately so that packages can
-reliably be moved from one system to another system and still be able to
-build it there. Cabal is therefore relatively strict about specifying
-dependencies. For example Cabal's default build system will not even let
-code build if it tries to import a module from a package that isn't
-listed in the `.cabal` file, even if that package is actually installed.
-This helps to ensure that there are no "untracked dependencies" that
-could cause the code to fail to build on some other system.
-
-The explicit dependency approach is in contrast to the traditional
-"./configure" approach where instead of specifying dependencies
-declarativly, the `./configure` script checks if the dependencies are
-present on the system. Some manual work is required to transform a
-`./configure` based package into a Linux distribution package (or
-similar). This conversion work is usually done by people other than the
-package author(s). The practical effect of this is that only the most
-popular packages will benefit from automatic package managment. Instead,
-Cabal forces the original author to specify the dependencies but the
-advantage is that every package can benefit from automatic package
-managment.
-
-The "./configure" approach tends to encourage packages that adapt
-themselves to the environment in which they are built, for example by
-disabling optional features so that they can continue to work when a
-particular dependency is not available. This approach makes sense in a
-world where installing additional dependencies is a tiresome manual
-process and so minimising dependencies is important. The automatic
-package managment view is that packages should just declare what they
-need and the package manager will take responsibility for ensuring that
-all the dependencies are installed.
-
-Sometimes of course optional features and optional dependencies do make
-sense. Cabal packages can have optional features and varying
-dependencies. These conditional dependencies are still specified in a
-declarative way however and remain compatible with automatic package
-management. The need to remain compatible with automatic package
-management means that Cabal's conditional dependencies system is a bit
-less flexible than with the "./configure" approach.
-
-### Portability ###
-
-One of the purposes of Cabal is to make it easier to build packages on
-different platforms (operating systems and CPU architectures), with
-different compiler versions and indeed even with different Haskell
-implementations. (Yes, there are Haskell implementations other than
-GHC!)
-
-Cabal provides abstractions of features present in different Haskell
-implementations and wherever possible it is best to ta[...incomplete...]
More information about the Pkg-haskell-commits
mailing list