packaging: Debian packaging is broken yet again

@texane

Current debian install rules to not take care to install the correct version.h that pretty much make the whole -dev package unusable.

@texane Just to remember, I'll try to dive and fix it when I have a spare minute.

I quote:

Do we really need to duplicate all the file installation rules in debian/rules? I suggest we do as much of the installation as possible with CMakeLists.txt, so that debian/rules would do as much as possible automatically.

Is there any rationale for building both debug and release builds of stlink when packaging?

I agree. we need to use the install target of cmake.
We building a package we should only build release.

Use of cmake install would be better in terms of maintenance.

I am not sure how to tell cmake where to install
adapt debian/*.install files to copy from cmake install dir, instead of from debian/tmp
or you can manage to install to debain/tmp with cmake
cmake should handle multiarch library paths
Just that tests depends on debug build. The build stage calls make all and all depends on release. The tests stage calls make test and test depends on debug. This is why both where build. I think automated tests where a good thing and should run, but you can disable it by add override_dh_auto_tests: to debian/rules, if you want.

You can tell cmake to install into DESTDIR with make install. See https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html (stackoverflow question)

@OsterlaD

@OsterlaD As @texane noted, you can just add DESTDIR= make install. In debian rules you don't have to mention this, as default debian stuff gets the job done already. Basically:

override_dh_auto_configure:
        dh_auto_configure -- \
        -DCMAKE_LIBRARY_PATH=$(DEB_HOST_MULTIARCH)

Is the only thing required and the only thing that I keep around my cmake-based projects. dpkg does the rest automatically.

@texane For my projects (See http://github.com/nekromant/aura) I add tests for production builds as well, but only those that don't require hardware connected by default. They are just not installed during the 'make install' phase. If dpkg-buildpackage won't find any tests it just won't run any, and since we have a CI I really think we can safely skip tests for packaging.

@nekromant

@nekromant i'm @xor-gate :=) not @texane :D

I thought about this way too.
dh_auto_build will call make all, which calls cmake at its own.
This is why dh_auto_configure has no effect.
So I removed code from dh_auto_configure.
There is no make install.

We could add make install to the toplevel Makefile which just calls make install in the release build

Sounds good. Maybe I have some time to try it later on.

@xor-gate

@xor-gate I'll give it a proper try tomorrow. And sorry for the typo. Tough day.

#484 use of make install

Lintian has some suggestions

rename package to libstlink1, but that conflicts cmake libstlink look-up
move lib links to dev pkg

I would like to add a postinst script to libstlink to reload udev rules.

I think this is now completely resolved?

Finally closed by #485.

Navigation Menu

Repository navigation

packaging: Debian packaging is broken yet again #482

13 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

packaging: Debian packaging is broken yet again #482

Description

Activity

xor-gate commented on Sep 22, 2016

xor-gate commented on Sep 22, 2016

xor-gate commented on Sep 22, 2016

xor-gate commented on Sep 22, 2016

nekromant commented on Sep 22, 2016

xor-gate commented on Sep 22, 2016

OsterlaD commented on Sep 22, 2016

xor-gate commented on Sep 22, 2016

OsterlaD commented on Sep 22, 2016

nekromant commented on Sep 22, 2016

OsterlaD commented on Sep 22, 2016

xor-gate commented on Oct 9, 2016

13 remaining items

Nightwalker-87 commented on Mar 17, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions