El mar., 10 de jul. de 2018 15:46, Kyle Edwards <kyle.edwa...@kitware.com> escribió:
> 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. >
