Use of openSUSE's %license macros breaks the builds

[peti]

We've recently adopted use of %license in openSUSE because of https://bugzilla.suse.com/show_bug.cgi?id=1082318. Once we've switched from %doc to %license, though, our builds started to fail because the spec file installs that license file into some place A (which is listed in the %files section) and Cabal install that license file into some place B, the %_docdir, which is not listed in %files.

I suppose we could adapt our spec files to rm the second copy installed by Cabal, but this issue feels like something that's actually supposed to be fixed in ghc-rpm-macros.

Could you please help us figure out how to do that? We haven't found any obvious solution yet.

Cc: @mimi1vx

[juhp]

Could you paste an example build error?

[peti]

If you modify the package at https://build.opensuse.org/package/show/devel:languages:haskell:lts:11/ghc-mtl as follows

--- ghc-mtl.spec        (revision 3)
+++ ghc-mtl.spec        (working copy)
@@ -63,7 +63,7 @@
 %ghc_pkg_recache

 %files -f %{name}.files
-%doc LICENSE
+%license LICENSE

 %files devel -f %{name}-devel.files
 %doc CHANGELOG.markdown README.markdown

then the post-build checks will fail with this error:

[   10s] Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/abuild/rpmbuild/BUILDROOT/ghc-mtl-2.2.2-0.x86_64
[   10s] error: Installed (but unpackaged) file(s) found:
[   10s]    /usr/share/doc/packages/ghc-mtl/LICENSE
[   10s] 
[   10s] 
[   10s] RPM build errors:
[   10s]     Installed (but unpackaged) file(s) found:
[   10s]    /usr/share/doc/packages/ghc-mtl/LICENSE
[   11s] 
[   11s] tw-dev failed "build ghc-mtl.spec" at Mon Apr  2 18:15:01 UTC 2018.

[juhp]

I see. What directory do you use for %license in SUSE?

In Fedora we have /usr/share/licenses/ghc-mtl/LICENSE.

[juhp]

Have you compared macros.ghc-fedora and macros.ghc-suse? In particular %_ghcdocdir.

[peti]

SUSE uses /usr/share/licenses/ghc-mtl/LICENSE, just the same.

[juhp]

I think you need to set %_ghcdocdir then like I do in macros.ghc-fedora.

I can update the suse file...

[peti]

Yes, indeed. If I add

%define _ghcdocdir %{_ghclicensedir}/%{name}

to the spec file, then the mtl build succeeds fine. Thanks!

[peti]

Um, actually, this solution is not very good, to be honest. What this does is that it passes --docdir=/usr/share/licenses/PKGNAME to the configure stage, but packages can (and do) install other documentation into that directory which are not licenses! See lhs2tex as an example. That build fails because now we end up having user documentation installed into the license directory.

[juhp]

That's true, but I think it works for like 95+% of packages, no? Cabal should really have --licensedir... But which is better? Putting the license file into the right place for like "99%" of packages or having to remove it from docdir for all. We can make cabal-rpm (cabal2spec) handle the exceptions.

[peti]

I think that it doesn't matter which alternative we choose. Both ways will work for some packages and will need fixing for others, so as far as I am concerned the effort involved is equal in either case.

Personally, prefer that we pass a location to --docdir that is actually intended for documentation, and then we move the the license files from there into %licensedir as part of %install. It's not pretty, but it feels like the cleanest solution.

Meanwhile, I have created https://github.com/haskell/cabal/issues/5281.

[juhp]

I tried to implement --licensedir and made a PR...

Basically every package has a license file but only a few have docfiles: so while I tend to agree with what you say, I don't agree that is doesn't matter which way. Unfortunately ghc-rpm-macros can't do the (re)moving yet since it is not "clever" enough (ie doesn't know what license file(s) or docfiles are present: it would be nice to have a client to query .cabal files). So while I admit it is a slight hack I still feel the current way is better.

Am I correct in thinking this only affects packages that install docfiles with custom Setup?

[peti]

ghc-rpm-macros can't do the (re)moving yet since it is not "clever" enough

I would have assumed that cabal-rpm or cabal2spec would generate the necessary mv command automatically. I wouldn't expect the ghc-rpm-macros to know about that.

Am I correct in thinking this only affects packages that install docfiles with custom Setup?

Yes, I think so.

[juhp]

Thanks, any idea how many packages are affected?

[peti]

Sorry, but I don't know ...

[juhp]

Okay I will try to play with lhs2tex.

edit: hmm it tries to create /usr/share/texlive/texmf-local/tex... I guess i can work around that... Or is there any other example?