El martes, 3 de julio de 2018 16:56:42 -03 Kyle Edwards escribió: > Hello everyone!
Hi Kyle! > My name is Kyle. I work at Kitware, Inc., the upstream maintainer of > the CMake buildsystem (https://www.cmake.org/) and VTK, the > Visualization Toolkit (https://www.vtk.org/). I'm Lisandro and, even if I'm listed as one of Debian's CMake maintainers I must admit I barely have put my hands into it's packaging. But on the other side I happen to maintain Qt (which does not uses CMake) and a lot of Qt based applications (which *do* use CMake). I even use it for 99% of my personal/job projects! > As some of you on the > Debian Science list may have heard, we are making an effort to > officially support our flagship product, VTK, on Debian and its > derivatives. To that end, we have created a new set of Debhelper > utilities to meet the unique challenges of packaging a large CMake- > based project like VTK. We have named this project "dh-cmake". It > allows Debhelper to take advantage of some of the more advanced > capabilities of CMake. For example: > > * CMake's install() command takes an optional COMPONENT parameter, > which allows you to break the installation up into multiple > "components", such as "Libraries" and "Development". dh-cmake allows > you to assign these components to separate binary packages, to avoid > having to enumerate every file or file glob in the *.install files. A thing that it's not clear to me: can the Debian maintainer override whatever upstream has set in there? If upstream happens to be the Debian maintainer then *maybe* this might be desirable. But if upstream is *not* the Debian maintainer then the later must be able to easily override whatever upstream has planned as "packaging". I mean: upstreams normally know how to develop their code, and maintainers know how to properly deploy it on their distro. If i as a maintainer need to hack CMake files in order to make a package install stuff in the right place then I would simply prefer to override whatever upstream has done and use our tooling. > * Projects that are CTest-aware can optionally have the output of > dh_auto_configure, dh_auto_build, and dh_auto_test captured by CTest > and submitted to a CDash server as part of a continuous integration > process. This is very useful for making sure a large software project > builds properly on Debian. Debian buildds do not allow network connections. Except maybe if some day we deploy something specifically for this. > * CPack includes a mechanism to declare dependencies between > installation components, for example, stating that the "Development" > component depends on the "Libraries" component. dh-cmake can > propagate this information into the output packages, so that > libexample-dev will automatically depend on libexample. And we are back to my first comment. > You can download the source code at > https://gitlab.kitware.com/debian/dh-cmake, and read more details about > the rationale and how it works. You can also install the binaries from > our own APT repository. Follow the instructions at > https://apt.kitware.com/ to set up the repository, and then install the > "dh-cmake" package. > > Our end goal is to get both dh-cmake and VTK into Debian proper, but it > is still in an experimental state, and there is still a lot of work to > be done yet. We would like to get some feedback on dh-cmake, and we > will eventually file a formal ITP and RFS for it as it becomes more > mature. We would also like to see other CMake-based packages follow our > lead and use these utilities. If you have a package that uses CMake, we > encourage you to give dh-cmake a try. > > Thank you in advance for the feedback. We are very excited to venture > into Debian development. Well, my feedback is clear: if we maintainers do not have an easy way to override upstream's *packaging* decisions then I will clearly not suggest fellow maintainers to use dh-cmake. All that being said discussing details in this list might be appropiate. We might find a use for it which suites both sides :-) Kinds regards, Lisandro. -- La ciencia sin la religión es renga, la religión sin la ciencia es ciega. Albert Einstein Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
