[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-buildsystem
Subject:    Re: Strange commit to FindKDE4Internal.cmake
From:       Pau Garcia i Quiles <pgquiles () elpauer ! org>
Date:       2012-02-19 22:46:02
Message-ID: CAKcBoksWT3gPV=RwDHqvvHzXci9gec1KgiEJL-fjZzfEnq09GA () mail ! gmail ! com
[Download RAW message or body]

On Sun, Feb 19, 2012 at 11:41 PM, Ralf Habacker
<ralf.habacker@googlemail.com> 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<lib>... 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<lib>... to the
library package. He needs not write anything new or look for
Find<lib>... anywhere else. If the original source tarball (i. e.
upstream) includes Find<lib>..., 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
[prev in list] [next in list] [prev in thread] [next in thread]