Source: haskell-reactive-banana
Maintainer: Debian Haskell Group <pkg-haskell-maintainers@lists.alioth.debian.org>
Uploaders: Clint Adams <clint@debian.org>
Priority: extra
Section: haskell
Build-Depends: debhelper (>= 9),
 haskell-devscripts (>= 0.9),
 cdbs,
 ghc,
 ghc-prof,
 libghc-hashable-dev (>= 1.1),
 libghc-hashable-dev (<< 1.3),
 libghc-hashable-prof,
 libghc-unordered-containers-dev (>= 0.2.1.0),
 libghc-unordered-containers-dev (<< 0.3),
 libghc-unordered-containers-prof,
 libghc-vault-dev (>= 0.3),
 libghc-vault-dev (<< 0.4),
 libghc-vault-prof,
Build-Depends-Indep: ghc-doc,
 libghc-hashable-doc,
 libghc-unordered-containers-doc,
 libghc-vault-doc,
Standards-Version: 3.9.4
Homepage: http://haskell.org/haskellwiki/Reactive-banana
Vcs-Browser: http://darcs.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/haskell-reactive-banana
Vcs-Darcs: http://darcs.debian.org/pkg-haskell/haskell-reactive-banana

Package: libghc-reactive-banana-dev
Architecture: any
Depends: ${haskell:Depends},
 ${shlibs:Depends},
 ${misc:Depends},
Recommends: ${haskell:Recommends},
Suggests: ${haskell:Suggests},
Provides: ${haskell:Provides},
Description: small but solid library for FRP${haskell:ShortBlurb}
 The current focus of this library is to implement a subset of the semantic
 model for functional reactive programming pioneered by Conal Elliott.
 .
 Moreover, this library can hooked into any existing event-based framework.
 It is especially useful in conjunction with existing GUI frameworks like
 wxHaskell or gtk2hs.
 .
 This also means that your code can be a mix of FRP and imperative parts.
 Bored of programming imperative GUIs? Write some parts with FRP! Don't know
 how to express something with FRP? Switch back to imperative style!
 .
 In the spectrum of possible FRP implementations, this one features simple
 semantics but modest expressivity. Predicting space & time usage should be
 easy.
 .
 Stability forecast: Known inefficiencies that will be addressed. No
 semantic bugs expected. Significant API changes are likely in future
 versions.
 .
 ${haskell:Blurb}

Package: libghc-reactive-banana-prof
Architecture: any
Depends: ${haskell:Depends},
 ${misc:Depends},
Recommends: ${haskell:Recommends},
Suggests: ${haskell:Suggests},
Provides: ${haskell:Provides},
Description: small but solid library for FRP${haskell:ShortBlurb}
 The current focus of this library is to implement a subset of the semantic
 model for functional reactive programming pioneered by Conal Elliott.
 .
 Moreover, this library can hooked into any existing event-based framework.
 It is especially useful in conjunction with existing GUI frameworks like
 wxHaskell or gtk2hs.
 .
 This also means that your code can be a mix of FRP and imperative parts.
 Bored of programming imperative GUIs? Write some parts with FRP! Don't know
 how to express something with FRP? Switch back to imperative style!
 .
 In the spectrum of possible FRP implementations, this one features simple
 semantics but modest expressivity. Predicting space & time usage should be
 easy.
 .
 Stability forecast: Known inefficiencies that will be addressed. No
 semantic bugs expected. Significant API changes are likely in future
 versions.
 .
 ${haskell:Blurb}

Package: libghc-reactive-banana-doc
Architecture: all
Section: doc
Depends: ${misc:Depends},
 ${haskell:Depends},
Recommends: ${haskell:Recommends},
Suggests: ${haskell:Suggests},
Description: small but solid library for FRP${haskell:ShortBlurb}
 The current focus of this library is to implement a subset of the semantic
 model for functional reactive programming pioneered by Conal Elliott.
 .
 Moreover, this library can hooked into any existing event-based framework.
 It is especially useful in conjunction with existing GUI frameworks like
 wxHaskell or gtk2hs.
 .
 This also means that your code can be a mix of FRP and imperative parts.
 Bored of programming imperative GUIs? Write some parts with FRP! Don't know
 how to express something with FRP? Switch back to imperative style!
 .
 In the spectrum of possible FRP implementations, this one features simple
 semantics but modest expressivity. Predicting space & time usage should be
 easy.
 .
 Stability forecast: Known inefficiencies that will be addressed. No
 semantic bugs expected. Significant API changes are likely in future
 versions.
 .
 ${haskell:Blurb}