On Thu, 2018-07-05 at 14:04 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > From what you write above I tend to think that simply by not using > dh-cmake whatever upstream has defined as packaging it will be simply > ignored (ie, it will become a "standard" CMake project).
Yes, this is true. dh-cmake only adds optional new functionality and doesn't take anything away from existing packages. > Now it turns out that you get a bug report where you need to split > the packaging. It's not an upstream issue per-se, but rather a > packaging one. Following normal Debian workflow that would mean > simply creating a new Debian revision. In our opinion, this actually *is* an upstream issue. To explain why, I think it would help if I give a brief explanation of the CMake philosophy. CMake is intended to be a high-level, cross-platform buildsystem that lets the end user use whatever tools they like most. Barring hard technical limitations (such as functionality that is highly specific to one operating system), if a CMake project is written properly, the developer and end user should be able to: * build and run the software on their operating system of choice, whether it be Windows, Mac, or Linux (among others), * generate build files for their favorite build tools (Makefiles, Ninja files, or project files for various IDEs), and * through the use of CPack, generate installers in whichever format they desire, including .deb, .rpm, WiX for Windows, and .dmg for Mac. Expanding on the third point, ideally, upstream would properly split the project output into components that have all the files in the right place. Then, the end user can generate well-formed packages in any format they want with CPack, or, in this case, with dh-cmake in cooperation with CPack. If any of these assumptions don't hold true, then the project isn't utilizing CMake to its full potential, and it can create a poor experience for the end user if they can't use the tools they feel most comfortable with. In this case, if a Debian developer can't generate a package from it using dh-cmake, then we consider it an upstream bug. > What would happen with dh-cmake? Would be a new upstream release > required? Would the package maintainer need to patch the packaging > editing a CMake file? In a word, yes. See my comment above about this being an upstream issue. Of course, many upstream projects won't do things correctly, and the Debian maintainer will have to do a lot of work no matter what tools they use. We realize this is unavoidable. In that case, the solution is to package it as a "traditional" Debian CMake package, without dh- cmake, the way it's always been done. This project is meant for the subset of cases where upstream DOES package it correctly, leaving almost no work for the Debian maintainer - just add configuration files for dh-cmake and it's ready to go right away, complete with upstream's dependency graph and project description. > [+dfsg] Maybe you can work out to fix this so a repackaging is not > needed? That would be *really* welcomed. I have a question about this (and I apologize if this is slightly off topic): VTK includes "convenience copies" of third-party libraries it uses to avoid "dependency hell", and also because we've made modifications to them that haven't yet been upstreamed. I know that on Debian it's not allowed to *use* these libraries (and we have flags to use the system versions instead), but do they have to be removed from the tarball entirely to comply with DFSG? If the DFSG modifications are because of a non-free file in VTK, we would certainly like to know about it, and possibly try to fix it. We don't intend to distribute anything with VTK that's under a non-free, restrictive license. Kyle
