On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker wrote: > There is a linux rpm package installing about 150 Find... scripts into > /usr/share/cmake-2.8/modules =A0(the package is named cmake) and a 3rdpar= ty > library rpm package installing a dedicated Find... script into the same > location (or a well known 3rdparty location) because the related Find. > script is not in the cmake binary package ? Is this forbidden ? On Debian, this is considered a bug. Really. > Is the library package maintainer be forced to add his Find... script > to the official cmake release or to a dedicated > extra-cmake-find-script-repository and tell the user to install an > additional dependency ? The library package maintainer must only add this Find... to the library package. He needs not write anything new or look for Find... anywhere else. If the original source tarball (i. e. upstream) includes Find..., then it will be installed in /usr/share/doc/libfoo-dev/cmake. > And when his Find... script is not accepted by the > cmake maintainers for whatever reasons, I never mentioned this Find... script would ever be submitted to CMake maintainers. It should not. > he has to add his Find.. to the > source and add a note to the library doc as mentioned above and the Find.= .. > script has to be added to every client library or application ? I never mentioned that either. It's upstream's duty to include Find... in the source tarball, not the packages maintainers. > And on each change in this Find... script every client library or executa= ble > maintainer has to update the copy by hand and may result into mysterious > failures with increased maintenance =A0otherwise. Once more: maintainers must only package and install what comes from upstream, nothing new. To avoid duplication, I propose this /usr/share/cmake-2.8/Modules-like directory where *official* 3rd party modules (i. e. the one that is installed with libfoo-dev, which is provided by upstream) would be installed. > Make this all sense ? As I proposed it, I think it does. -- = Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem