https://bugzilla.redhat.com/show_bug.cgi?id=1069988 --- Comment #11 from Christopher Meng <cickumqt@xxxxxxxxx> --- (In reply to Sven Nierlein from comment #10) > Some updates... As thruk developer and naemon core dev like Dan i hopefully > can help to change things to fit the fedora requirements. Thanks! > 6. This would be the package name of the standalone gui. Its not a official > fedora package atm. It can go if it violates any packaging guidelines. One package conflicts with a package non-existing forever, uh? ;) > 9. What exactly is the problem here? Should we just skip the devel package? > Or should we provide full %attr? Unclear sorry, see: https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries "Static libraries should only be included in exceptional circumstances. Applications linking against libraries should as far as possible link against shared libraries not static versions." Thus you'd better remove static libraries. > 10. .o is the file extension for nagios/naemon loadable objects. Got it, thanks! > 12. This does not skip tests entirely, but does not build extented tests > which would require additional dependencies. Since full tests are done on > travis-ci, we skiped them during packaging. Thanks for the clarification! > 16. The Perl modules are the reason why we used AutoReqProv:no in > naemon-thruk and naemon-thruk-libs. In an ideal world, all required perl > modules would exist as packages already, then we could just skip the libs > package and use requires entirely. Thruk itself looks like a perl module for > cleaner development, but is a catalyst perl application, so it does not > provide any perl modules. > I could probably rewrite this to use > %global __provides_exclude_from ... > %global __requires_exclude_from ... That's dirty, AutoReqProv:no is not allowed to be used now. This case matchs bundled libraries, you must remove them and use the system shipped. > 17. %if %{defined suse_version}: > We tried to make a universal spec file which fits most systems. We could of > course create a fedora only spec file. But i see little benefit, it just > creates maintainance overhead. If this is a strict requirement, we could > maybe provide a script to automatically remove these tags on building the > fedora source packages. Yes, since providing such is nonsense(trust me). SUSE's way of packaging is not good from the view of Fedora sometimes. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review