Kyle Edwards writes ("Re: A message from CMake upstream: announcing dh-cmake"):
> I understand what you're saying. As a concrete example, we all know
> that Debian requires *.so library symlinks to live in the -dev package.
> But let's say there's a hypothetical Debian derivative that requires
> them to live in the library binary package instead.
>
> If upstream has both the headers and the symlink in the "Development"
> component, then this would certainly be a problem. Perhaps the solution
> is for upstream to make this more flexible, through one of several
> options:
You have missed an option, which is for that derivative to use the
existing upstream components, and dh-cmake, etc., which put the
symlink in the wrong package for them, *and then to fix up that
wrinkle afterwards*.
This kind of thing is entirely normal in packaging.
I really don't agree with the thrust of Lisandro's comments. AFAICT
what Lisandro is saying is this: because the upstream components may
not always be perfect; and even may be totally inappropriate; they are
useless or harmful for packaging for Debian.
The usual case is that the upstream components are mostly right.
If they are slightly wrong, then the right thing to do is to fix them
(carrying the patch in Debian until it makes it through into the
appropriate upstream release), or if upstream don't want the fix for
any reason, to carry that patch forever, or to write a workaround
which fixes it up and carry that forever in debian/rules.
If there is a systematic mismatch, it is normally possible to invent a
systematic fixup. That is an alternative to adding a feature to the
upstream component system to do things differently.
We have taken all of these approaches in various packages. Which to
choose is a matter of judgement, and of course any one of them may be
inappropriate in particular circumstances. But that does not mean
that upstream component systems are harmful or dangerous or that they
should be discouraged or ignored. The usual case will be that it is
easiest to use the upstream component system and deal with any
problems with it in any one of the usual ways we deal with problems
with upstream functionality.
Given that upstream component systems will often be useful, especially
if they are done with a bit of care, it is a very good thing to have a
build tool which can use them automatically.
So, in summary, if I were packaging one of the pieces of software
which dh-cmake is aimed at, I would probably want to use it. Thanks,
Kyle (and your colleagues) for this work. This work sounds excellent
to me. Please do not be discouraged.
I did have some minor technical question when I read the original
posting. But it's not important. It is more important to applaud
what you are doing.
Thanks,
Ian.
