search

juhp / cabal-rpm

Haskell Cabal RPM packaging tool
https://hackage.haskell.org/package/cabal-rpm
GNU General Public License v3.0
25 stars 8 forks source link

spec: declare binaries in the main package, not in the -devel package #44

Closed peti closed 8 years ago

peti commented 8 years ago

Found by @mimi1vx.

juhp commented 8 years ago

As usual a 'testcase'/example would be helpful..

So for Library packages with a binary, you want the binary to live in the base library package, right? That might be reasonable - though I don't have any good examples. In general I would argue in that case probably the Binary should live in its own binary package.

juhp commented 8 years ago

Let me give a little more explanation for the current behaviour. Earlier cabal-rpm (and its predecessor cabal2spec I think) would always name any package with a binary by the hackage package name (so pandoc becomes pandoc (good), derive becomes derive (less good, since I don't think many people need/use the derive program standalone - so it makes more sense to put it in the devel package), and worse for highlighting-kate, aeson-pretty, yaml, etc. Therefore to discourage people from packaging libraries as BinLib packages I changed the default for cabal-rpm to always assume a library package is a Lib package even if it includes some unimportant executable. Mostly executables in library packages don't seem that important (often they should not even be built by default to be honest) and when they are important we should package them with --binary option anyway.

eg from Fedora:

$ grep --color -nH -e bindir ghc-*/master/*.spec
ghc-aeson-pretty/master/ghc-aeson-pretty.spec:81:%{_bindir}/%{pkg_name}
ghc-derive/master/ghc-derive.spec:76:%{_bindir}/%{pkg_name}
ghc-hakyll/master/ghc-hakyll.spec:117:%{_bindir}/hakyll-init
ghc-hgettext/master/ghc-hgettext.spec:67:%{_bindir}/%{pkg_name}
ghc-highlighting-kate/master/ghc-highlighting-kate.spec:102:%{_bindir}/%{pkg_name}
ghc-hjsmin/master/ghc-hjsmin.spec:70:%{_bindir}/%{pkg_name}
ghc-pretty-show/master/ghc-pretty-show.spec:91:%{_bindir}/ppsh
ghc-yaml/master/ghc-yaml.spec:103:%{_bindir}/json2yaml
ghc-yaml/master/ghc-yaml.spec:104:%{_bindir}/yaml2json

I am not sure it particularly makes sense to put any of these binaries in the base (library) package.

How do you think?

mimi1vx commented 8 years ago

I think in almost all cases is better to have binaries in ghc-package than ghc-package-devel

and in case is main usage pattern binary we must excplictly force --binary flag ..

for example in opensuse is texmath and highligting-kate forced to binary package .. both provides full funkcionality in binary ... and are usable without use of lib.

on other side yaml is ghc-yaml with binaries in ghc-yaml as working example ( and very fast converters) for library

Packager must decide which is main use for binaries in BinLib package ..

juhp commented 8 years ago

Okay, but do many people really use those executables much (texmath, highlighting-kate, yaml)? Well maybe I should be fighting this fight upstream instead... trying to persuade them not to creating executables by default?

What's right in the end it is the packager's call I think. Personally I prefer not to put executables into the base library package.

Maybe we can make this minor change SUSE specific? If you prefer to always have a binary package for executables for SUSE we can do that too.

Perhaps at some point we should modularize Spec.hs more, to make it easier to have SuseSpec and FedoraSpec, etc say... (We also really really need tests.)

juhp commented 8 years ago

I am happy to make this SUSE specific for now.

peti commented 8 years ago

Automatically removing installed data files feels a bit risky to me. After all, we don't know whether the package author may rely on these files being available somehow. Personally, I think it would be better to have cabal-rpm print out a warning in this case so that a human can investigate what is going on and -- preferably -- try to convince upstream to stop declaring documentation as data files in their Cabal file.

Maybe it would be a good idea to enable/disable the feature that generates those rm statements with a command line flag? That way, users of cabal-rpm had a way to choose what they think is best.

juhp commented 8 years ago

I think a warning is a good idea. I am not so keen on lots of flags (and code paths) but rather in favour of good default behaviour. eg we could probably drop --strict and just make it the default behaviour.

If you prefer we could just emit a warning for now, that is okay for me. Maybe I will make the removal specific to Fedora then, or drop it after further testing.