Created attachment 866852 [details] ShellCheck.spec-1.patch Description of problem: The attached patch makes some small tweaks to make the spec safer: - only create symlink if one doesn't exist already - separately package LICENSE/README for ShellCheck and ghc-ShellCheck to avoid update issues The latter prevents update issues if you try to update ShellCheck and ghc-ShellCheck* separately for some reason.
For reference, this is the error message with *ShellCheck* already installed: $ sudo yum update ghc-ShellCheck* : Transaction check error: file /usr/share/doc/ShellCheck/README from install of ghc-ShellCheck-0.3.1-3.fc20.x86_64 conflicts with file from package ShellCheck-0.2.0-3.fc20.x86_64 file /usr/share/doc/ShellCheck/README from install of ghc-ShellCheck-devel-0.3.1-3.fc20.x86_64 conflicts with file from package ShellCheck-0.2.0-3.fc20.x86_64
Hi, Thanks for the patch and I hope you enjoy the packages :) Would it make more sense to have ShellCheck strictly depend on ghc-ShellCheck ? It seems that the main package doesn't link to its shared library but embeds it statically instead. That shouldn't happen according to the main guidelines, but it doesn't seem to be a problem according to the Haskell guidelines (no Requires tag in the `Library and Binary' template).
> Would it make more sense to have ShellCheck strictly depend on > ghc-ShellCheck ? Yes, but it should be done at the .cabal level not explicitly in the spec file. Pandoc does this for example and so does Agda: it is particularly desirable large packages. > It seems that the main package doesn't link to its shared library but embeds > it statically instead. That shouldn't happen according to the main > guidelines, but it doesn't seem to be a problem according to the Haskell > guidelines (no Requires tag in the `Library and Binary' template). Right - it needs some massaging of the .cabal file, etc. It should not be very hard but one might need to experiment a bit. In theory adding "depends: ShellCheck to the executable section ought to be enough but in practice it doesn't seem to be. Either way I would be curious to see the final changes that make it work since I would also like to know how to do it, but if you run into difficulties I can also try to help with it. Looking at the other examples hopefully we can work it out.
> That shouldn't happen according to the main guidelines, > but it doesn't seem to be a problem according to the Haskell > guidelines (no Requires tag in the `Library and Binary' template). (Right it is not mandatory for Fedora Haskell packages and by default Cabal does not self-link executables.)
Created attachment 868345 [details] switch to dynamic linking I've attached a quick n dirty patch for my spec that switches to dynamic linking. That should solve the upgrade issue: $ rpm -qpR /var/lib/mock/fedora-rawhide-x86_64/result/ShellCheck-*.x86_64.rpm | grep ShellCheck ghc(ShellCheck-0.3.1-d837c7bb20080c4086df07bc61506f2a) libHSShellCheck-0.3.1-ghc7.6.3.so()(64bit) If it sounds good to you I'll try to upstream my modifications to the cabal file and update the package in rawhide.
Yes, the changes to the .cabal look good. I think it should be good for upstream. (If you want to build that first for Rawhide you should do it as a patch really.)
So after that anyway it should be sufficient just to have the 2 doc files in ghc-ShellCheck. :)
(In reply to Jens Petersen from comment #6) > (If you want to build that first for Rawhide > you should do it as a patch really.) Of course, I posted the "quick n dirty" fix just to make sure we both agree on this solution. I'll make a proper patch and send this uptsream, so that I can link to a URL in upstream's issue tracker once I integrate the patch for Fedora.
Patch merged upstream: https://github.com/koalaman/shellcheck/pull/105 https://github.com/koalaman/shellcheck/pull/105.diff Update coming soon in rawhide ! (In reply to Jens Petersen from comment #7) > So after that anyway it should be sufficient just to have the 2 doc files in > ghc-ShellCheck. :) I'd rather keep the files in the main package (ShellCheck) pkgdocdir.
Build successful: http://koji.fedoraproject.org/koji/taskinfo?taskID=6583468
ShellCheck-0.3.1-4.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ShellCheck-0.3.1-4.fc20
ShellCheck-0.3.1-4.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ShellCheck-0.3.1-4.fc19
Package ShellCheck-0.3.1-4.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ShellCheck-0.3.1-4.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-3342/ShellCheck-0.3.1-4.fc20 then log in and leave karma (feedback).
My apologies - you need one more thing in ShellCheck.spec for the selflinking of the executable to work. Namely need to fix the rpath to the ShellCheck lib. I have a macro for that so if you add %ghc_fix_dynamic_rpath shellcheck towards the end of the %install section it should avoid this runtime error in ShellCheck-0.3.1-4.fc20: $ shellcheck shellcheck: error while loading shared libraries: libHSShellCheck-0.3.1-ghc7.6.3.so: cannot open shared object file: No such file or directory Sorry I forgot to mention that earlier: to prevent this bad build going stable I undid the stable requests in Bodhi. (Just noticed this by chance since I wanted to use shellcheck on a script now, I should have tested more carefully earlier.:)
For some reason I got an email notification for your bodhi comment but not this one. I solved it with a drop-in conf for ld, I'll fall back and use your macro instead.
I've tried to use the macro but it doesn't seem to work: === @@ -79,6 +79,7 @@ make shellcheck.1 %install %ghc_lib_install +%ghc_fix_dynamic_rpath shellcheck # currently no pandoc on arm (bug #992430) %ifnarch %{arm} === The rest of the install section is just a copy of the man page (except on arm currently). And then when I check: ldd /usr/bin/shellcheck | grep ShellCheck libHSShellCheck-0.3.1-ghc7.6.3.so => not found ShellCheck-0.3.1-5 should fix this, can you have a look at it once it's available on rawhide ? http://koji.fedoraproject.org/koji/taskinfo?taskID=6637764
(In reply to Dridi Boukelmoune from comment #16) > I've tried to use the macro but it doesn't seem to work: > +%ghc_fix_dynamic_rpath shellcheck > And then when I check: > ldd /usr/bin/shellcheck | grep ShellCheck > libHSShellCheck-0.3.1-ghc7.6.3.so => not found You're right: this is again because $(cwd) != %{pkg_name}-%{version} :-| It would really make life (and you .spec file;) a lot easier if you could move to the hackage tarball... > ShellCheck-0.3.1-5 should fix this, can you have a look at it once it's > available on rawhide ? > http://koji.fedoraproject.org/koji/taskinfo?taskID=6637764 Okay that did workaround the rpath issue but I don't think it is nice leaving the incorrect RPATH in shellcheck. So I added a "modified" %ghc_fix_dynamic_rpath to the spec file in ShellCheck-0.3.1-6.fc21 which takes into account the source dir name. I suppose arguably it could be a ghc-rpm-macros bug but this package is the only exception currently. It seems to work okay for me anyway.
I really need to fix bug #1052117 then, because the tarball from hackage is still not usable in its current state. Thanks for the workaround.
ShellCheck-0.3.1-6.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ShellCheck-0.3.1-6.fc19
ShellCheck-0.3.1-6.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ShellCheck-0.3.1-6.fc20
ShellCheck-0.3.1-6.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
ShellCheck-0.3.1-6.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.