Web lists-archives.com

Re: A message from CMake upstream: announcing dh-cmake

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 

> * 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

Attachment: signature.asc
Description: This is a digitally signed message part.