Spec URL: http://codeblock.fedorapeople.org/packages/aeson-pretty/aeson-pretty.spec SRPM URL: http://codeblock.fedorapeople.org/packages/aeson-pretty/aeson-pretty-0.7-1.fc20.src.rpm Description: A JSON pretty-printing library compatible with aeson as well as a command-line tool to improve readabilty of streams of JSON data. The /library/ provides the function "encodePretty". It is a drop-in replacement for aeson's "encode" function, producing JSON-ByteStrings for human readers. The /command-line tool/ reads JSON from stdin and writes prettified JSON to stdout. It also offers a complementary "compact"-mode, essentially the opposite of pretty-printing. Fedora Account System Username: codeblock
Any idea how important the tool is? Just wonder if it would be better to call this ghc-aeson-pretty?
(Actually lately I have been pondering on the frightening idea of renaming all the Haskell src packages to hackage-*! ;-)
I'm fine with calling this ghc-aeson-pretty (or hackage-aeson-pretty :P). aeson-pretty is what cblrpm defaulted to on this though. Should I just combine the subpackage it made (ghc-aeson-pretty) and the base package (aeson-pretty) into ghc-aeson-pretty?
You can use "cblrpm -l spec" to force a BinLib package to become Lib.
(Hmm perhaps cblrpm should just default all package with a library to be called ghc-*. I might do that in the next release.)
Sorry I see I didn't answer your actual question: > Should I just combine the subpackage it made (ghc-aeson-pretty) and the base > package (aeson-pretty) into ghc-aeson-pretty? Hmm it probably depends on the use case of the executable. For some packages we put the program into the devel package because that made sense. Another approach if it doesn't make sense to do that or to exclude the program, might also be to subpackage it as aeson-pretty. (Typically for libraries that include some test/demo program we just remove it completely.) (Other previous examples include highlighting-kate (rename review submitted) and ghc-derive (already renamed!).)
This package is needed for pandoc-citeproc. Do you want to update this? Otherwise I can start a new review.
*** This bug has been marked as a duplicate of bug 1058174 ***