Handle all debian/configure tasks using build profiles and options

[petterreinholdtsen]

Using the 'nodoc' Debian package profile and build option to
control the creation of documentation packages.

Updated minmum debhelper compat level from 9 to 10, matching the level
in Debian Buster. Drop code to set higher compat level on newer versions
of Debian.

Uses versioned alternative depends to control the readline and
texlive-xetex build dependency.

Updated all build scripts and documentation to reflect that the
debian/configure script is obsolete.

[jepler]

I've put the current "merge" version of this PR as a branch on linuxcnc/linuxcnc so that buildbot can try it out. The branch is called test-1835. If it passes on buildbot I'm good with merging this.

[jepler]

in particular a nodoc build profile will be loved!

[SebKuzminsky]

Our current packaging supports just one realtime target: Preempt-RT. Historically we have supported multiple realtime targets (with different build-dependencies), eg Preempt-RT and RTAI. We handled this by having debian/configure generate debian/control with different things listed in Build-Depends, and different package names (ie linuxcnc-uspace for Preempt-RT and linuxcnc-rtai for RTAI). How would this proposed PR handle that situation (assuming we ever manage to get packaging going for another realtime target)?

[petterreinholdtsen]

[Sebastian Kuzminsky]

Our current packaging supports just one realtime target: Preempt-RT. Historically we have supported multiple realtime targets (with different build-dependencies), eg Preempt-RT and RTAI. We handled this by having `debian/configure` generate `debian/control` with different things listed in `Build-Depends`, and different package names (ie `linuxcnc-uspace` for Preempt-RT and `linuxcnc-rtai` for RTAI). How would this proposed PR handle that situation (assuming we ever manage to get packaging going for another realtime target)?

My approach would be to use build profiles for this, similar to how the nodoc profile is handled.

…

-- Happy hacking Petter Reinholdtsen

[jepler]

I'd like to add that, if we are bringing back an RTAI-based linuxcnc package, it should also be "uspace" using the "lxrt" API of RTAI. This means we don't need kernel modules (though we'd probably still be tied to a particular RTAI kernel version). This would involve a separate, additional "linuxcnc-uspace-lxrt" package, rather than an independent "linuxcnc" (non-uspace) package.

[jepler]

The build did succeed on buildbot: http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/8958

[smoe]

This looks good to me. My two concerns are that this may conflict with @SebKuzminsky's work in #1887 and that I do not have the immediate overview if the -A and -B flags still work (but they should, would accept this and then fix that if not working).

[petterreinholdtsen]

[Steffen Möller]

This looks good to me. My two concerns are that this may conflict with @SebKuzminsky's work in #1887 and that I do not have the immediate overview if the -A and -B flags still work (but they should, would accept this and then fix that if not working).

It is in direct conflict with #1887, and I believe we should merge #1887 first and then rework this pull request based on top of that one before reconsidering to merge this patch.

…

-- Happy hacking Petter Reinholdtsen

[smoe]

[Sebastian Kuzminsky]
Our current packaging supports just one realtime target: Preempt-RT. Historically we have supported multiple realtime targets (with different build-dependencies), eg Preempt-RT and RTAI. We handled this by having debian/configure generate debian/control with different things listed in Build-Depends, and different package names (ie linuxcnc-uspace for Preempt-RT and linuxcnc-rtai for RTAI). How would this proposed PR handle that situation (assuming we ever manage to get packaging going for another realtime target)?
My approach would be to use build profiles for this, similar to how the nodoc profile is handled.
…

These build profiles (https://wiki.debian.org/BuildProfileSpec) have d/rules interpret the DEB_BUILD_OPTIONS environment variable. I do not know how this can have an effect on the set of binary packages that d/configure influences since the d/control.*.in files would be gone, but d/rules has all the flexibility of the world. This also means that the dh commands could be passed various options to not create the one or other package.

[smoe]

Looked through it again and still liked it. The only concern is that this patch takes the need for debian/configure away (which is also the major motivation behind this PR). Some smallish updates are required beyond the conflicts now that the PR was bitrotting for quite a while. A safe thing to do for 2.10, unsure about 2.9 not knowing about how much our build infrastructure depends on the debian/configure script.

[andypugh]

One thing that configure does is decide which realtime system is being built for. It can be preempt-rt, RTAI, Xenomai, RTAi-LXRT OR Xenomai-LXRT. Admittedly all but two of those are very niche and probably have no actual users.
This sets flags that alter a lot of conditional compilation.

[smoe]

And if we just have more packages and build both preempt and RTAI as the presumed most common flavours?