Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: gwyddion https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187294 ------- Additional Comments From [EMAIL PROTECTED] 2006-09-12 05:59 EST ------- A quick note, there is a /sbin/ldconfig which is certainly forgotten in %postun (and another one, there are still dependencies on perl in -libs, but it could be sorted out when there is an agreement on the split) rpmlint output is now ignorable W: gwyddion-devel no-dependency-on gwyddion E: gwyddion-devel only-non-binary-in-usr-lib W: gwyddion-plugin-examples no-documentation (In reply to comment #27) > I'm not convinced the techincal details of how the interpreter is extended (it > dlopens a shared library and calls some functions -- or it reads and > interprets > some high-level code) affect what consistutes a dependency. That was not my point. What I was saying is that, unlike -devel package which is needed at compile time only, modules are needed at runtime, and are directly used (or run if you prefer) by the interpreter. Not important. > The work is not the problem for me. The problem is to introduce 3 more > subpackages, each with a single module and README.Fedora saying something > along > the lines `This module was made public due to Fedora requirements, but do not > actually use it.' This would be rather silly. I don't want to force you to do anything but package things consistently. I don't have any problem with not packaging at all the modules and example plugins. But in case they are packaged they should be packaged such that they are easy to use by users, which means that what the best would be to have them available as classical modules. And if it is not the case, they should be packaged like modules. > I'm not bothered much by the expectation-based dependency in the case of > pkgconfig, because the expectation is often right (unlike our case, although > you > don't agree) and pkgconfig is a small program without any further dependencies > (unlike for example python). But to require a tool *only* to get a directory > to > put files to, that would be indeed a packaging problem IMO. That won't necessarily be a packaging problem. Indeed you have to chose between alternatives regarding directory ownership, and none are pretty: * add a package that only holds the directory (filesystem) * depend on a package that holds the directory but also provide other and maybe unneeded things (pkgconfig, automake for /usr/share/aclocal/) * have all the packages own the directory (/usr/share/gtk-doc/html/) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
