Web lists-archives.com

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

Hi Lisandro,

Thank you for expressing your concerns. You bring up some very valid
points, and I will try to address all of them here.

On Wed, 2018-07-04 at 14:40 -0300, Lisandro Damián Nicanor Pérez Meyer
> I even use it for 99% of my personal/job projects!

Glad to hear it!

> 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".

You are correct that this works best if the upstream project has done
its packaging correctly, and/or if the upstream maintainer is also the
Debian maintainer. We would certainly like to see projects use CMake in
a way that makes the life of downstream maintainers easier, and the
install() command's COMPONENT parameter is designed specifically for
this purpose.

If upstream hasn't done its packaging correctly, then we would
certainly advise you to use your own judgment and possibly not use it,
or even try to get your changes upstreamed. (Though, there may be cases
where upstream gets it 99% correct, in which case the solution is
"install the 'Development' component in libexample-dev, then remove
this one file that shouldn't be there.")

In our case, we plan on using this to package VTK. Our plan is to
change VTK's upstream CMake scripts to make it more distro-friendly,
then provide packaging scripts that take advantage of these changes.
(We've already made some of these changes in the latest VTK master - it
now automatically installs its libraries in /usr/lib/<arch> if built as
a Debian package.)

> Debian buildds do not allow network connections. Except maybe if some
> day we deploy something specifically for this.

Not to worry, we've already thought about this. Even if the packaging
turns on the CTest functionality, dh-cmake won't actually try to submit
anything to a server unless the builder/developer gives it explicit
permission to do so, via the DEB_CTEST_OPTIONS environment variable
(this was inspired by DEB_BUILD_OPTIONS). This allows for packages that
simulaneously support two workflows: one for in-house development,
where the build machine gives permission to submit results to CDash,
and one for production (Debian's buildd instances) where it doesn't
submit anything, and just acts as a thin wrapper around the dh_auto_*

The CTest functionality isn't meant to be turned on in production
buildd instances. It's meant to be used as part of the continuous
integration/nightly build process of an upstream software project,
where a Debian package is one of the supported builds. In our case, we
plan on making Debian one of the supported nightly builds of VTK, and
having this information submitted to CDash is very valuable to us, as
it allows us to spot problems with the Debian build as they occur. VTK
is a very large project that is constantly growing, evolving, and
changing, and supporting it on Debian now and for the rest of the
foreseeable future requires the use of this workflow.

> All that being said discussing details in this list might be
> appropiate. We might find a use for it which suites both sides :-)

Yes, my hope is that we've designed this in a way that works for both
upstream and downstream. I think we've done our best to address all of
your concerns while also supporting upstream's needs.

Thanks again for the feedback!