[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



El viernes, 6 de julio de 2018 12:59:58 -03 Kyle Edwards escribió:
> 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.

That's just perfect.

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

[snip]

That's just perfect. It really sounds like a tool to use if upstream wants to 
provide a non-official Debian package, and believe me that sounds pretty good.

But not for Debian proper, see below.

[snip]
> 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.

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.

That's just an example, but I'm sure other will appear.

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.

Except we can find smart work arounds for this cases, of course.

Cheers, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

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


Reply to: