On Tue, 2018-07-10 at 12:52 -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
> Well, there are cases when upstream is doing things the right way
> with respect to Debian but... what about derivatives (distributions
> which base themselves in Debian)? Sometimes they need something
> different, and even if the package fits perfectly well in Debian it
> might not be true for them. So they need to either patch CMake files
> or re do the whole packaging using traditional tools.
I understand what you're saying. As a concrete example, we all know
that Debian requires *.so library symlinks to live in the -dev package.
But let's say there's a hypothetical Debian derivative that requires
them to live in the library binary package instead.
If upstream has both the headers and the symlink in the "Development"
component, then this would certainly be a problem. Perhaps the solution
is for upstream to make this more flexible, through one of several
options:
[Snip]
> To sum it up: I *do* think there is a *huge* potential for this
> helper, just not for Debian proper. Of course I would *love* to see
> it packaged in Debian because it will help projects trying to create
> their own Debian packages, but I would expect a very clear
> explanation that this is not a suitable way to maintain packages in
> Debian proper.
In fact, CPack already provides its own method for maintaining 3rd
party Debian packages - it has its own .deb generator. But dh-cmake is
our attempt to make something that fits better into the Debian
workflow, so that it *can* be used to maintain packages in Debian
proper.
We want CMake packaging to be as easy as Python packaging, where you
just activate dh-python. The end goal of dh-cmake is to make CMake
packaging as easy as writing a few configuration files, and then
declaring "dh $@ --buildsystem=cmake --with cmake --with ctest --with
cpack".
In our case, our goal is to maintain an official VTK package in both
Debian proper and Ubuntu proper. VTK is a huge project which has proven
to be difficult to package, and dh-cmake is being created to solve this
problem. We've also made changes to both VTK and CMake itself to
support the VTK packaging effort, and we can and will make more.
> Except we can find smart work arounds for this cases, of course.
I think making the component names configurable and/or standardized, as
I described above, would help tremendously with this.
I really applaud your effort. It's now clear to me that you are not trying to add just some logic around cpack but really are wanting to create a nice tool.
I would say just keep on with vtk packaging and tackle other cases as they appear.
Regards, Lisandro.