New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bring the debian folder into master #2353

markus2330 opened this Issue Jan 31, 2019 · 3 comments


None yet
2 participants
Copy link

markus2330 commented Jan 31, 2019

As discussed in #2350:

Yes, the current situation is really bad. Is there any reason not to have the files for building the debian package on the master branch, so that each PR could modify them separately?

The setup was as recommended by gbp buildpackage (at the time when I did it). But I fully agree it causes many problems (also the debian/copyright).

Following issues need to be resolved:

  • We need to find a way how we can bring the debian folder into the master branch, and still keep the build system happy (so that it still creates Debian packages),
  • The files in the debian branch, need to be relicensed to BSD (@pinotree is this acceptable for you?) or rewritten.

@kodebach kodebach referenced this issue Feb 6, 2019


kdb run_all does not execute external tests #2372

0 of 2 tasks complete

This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Feb 6, 2019

@kodebach wrote in #2372:

It should be possible to use CPack components to produce multiple packages. Might be worth investigating for #2353.

Yes, if @pinotree does not react and we need to reimplement the packages, this sounds like a viable option. This feature did not exist several years ago but seems to be now fully supported also with Debian packages (see The advantage would be, that we also get packages for Windows and Mac OS X. (See also #435, @beku said, he used components to build OS X frameworks and app bundles.)

@sanssecours What do you think?


This comment has been minimized.

Copy link
Contributor Author

markus2330 commented Feb 6, 2019

And one more thing: If we build the packages from within CMake, we can also use the dependencies as documented within plugins, see #1016 for the proposal.


This comment has been minimized.

Copy link

sanssecours commented Feb 6, 2019

What do you think?

Sounds like using CPack would improve the current situation, so I am definitely a proponent of switching the packaging build system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment