Re: [cmake][multipackaging] best practices
Hi, I guess your answers are in
man dh_python2
man dh_makeshlibs
man dh_shlibdeps
and so on
the first tries to evaluate the runtime dependencies of a python application
the others does almost the same for the built libraries.
they are needed to know which runtime dependencies the package will have.
(not sure if the list is comprehensive, other tools like haskell might have their own
haskell:Depends, or also dh_python-ply, dh_numpy, dh_ruby, dh_pypy, dh_sphinxdoc, dh_doxygen
and I don't know how many more).
Each dh helper tries to fix a well known problem in a particular piece of build system.
(so runtime dependencies needs to have XXX:Depends, to let the helper do the substitution)
exporting DH_VERBOSE=1 might give you an hint about which dependencies have been filled,
or (this is what I do), opening the generated deb file in the DEBIAN/control file will tell you the runtime
dependencies.
cheers,
G.
Il Mercoledì 4 Novembre 2015 10:28, Raffi Enficiaud <raffi.enficiaud@mines-paris.org> ha scritto:
Le 04/11/15 09:50, Gianfranco Costamagna a écrit :
> Hi, generating debian files from cmake is not trivial, and I'm not sure I can answer here.
Hi,
Thank you for your reply! Would you please tell me what are the
difficulties? I have more the developer hat, and not the packager one,
and to me it is a bunch of "install" commands in cmake (with proper
components and location), and "make" + "make package".
> Furthermore, in Debian we don't have this need, and generating them (autogenerating) is source
> of problems with official packages.
What I understood so far (please correct me) is that packaging a project
that is using cmake uses the "make" / "make install", so it is kind of
difficult to partition the generated files into several .deb files:
after the "make install", everything is under usr/xxx and then "dh"
takes over and creates one unique .deb file.
Also, this information might already be available in the cmake files
(since a project might be packaged in several platforms with the same
partition). So having the information replicated in the debian/* is a
redundancy that is not be needed. As it is now in the cmake project,
only a few files are needed under debian/ directory, and the hurdle of
maintaining the packages definition for the .deb files is deported to
the cmake side.
> So I'm afraid (while I like the opportunity), nobody will be interested in this list :(
That's a pity :)
> (BTW you seem to produce an old style rules file, without the new dh calls, and the control
> file has no shlibs:Depends, python:Depends and so on.)
Yes, I am really not an expert in "dh" and I do not understand what it
does exactly. I understand it can configure cmake with options, but the
support of cmake is limited to that (again, as I understand it).
So I sticked to the fact that debian/rule is just a Makefile :)
In the control file, I do not need "shlibs:Depends" since those are run
from cmake directly:
https://cmake.org/cmake/help/v3.4/module/CPackDeb.html?#variable:CPACK_DEBIAN_PACKAGE_SHLIBDEPS
python:Depends is also handled by the cmake (python version is in the
debian/rule that is passed to cmake). There should be a more elegant way.
When are those variables "python:Depends" getting expanded? is there a
tool that can return a string on all calculated dependencies before the
.deb is generated? (maybe a call to dpkg? how is it done in dh?)
>
> (but I did a really quick look)
Thanks again!
Raffi
Reply to: