Menu ▾ ▴

#362 debian/configure only configures flavors for running kernel and posix

future-release
open
nobody
None
5
2014-02-20
2014-02-20
John Morris
No

The debian/configure script will only configure binary packages for threads supported by the running kernel and posix. This is limiting in many environments, such as building on a system with no running RT kernel, or building in a chroot where the running RT kernel does not match any kernel in the distro.

The Universal Build has no requirement for a running, RT-enabled kernel. The requirements to build the various flavors are:

POSIX: no requirements (represented in current debian/configure)
PREEMPT_RT: no requirements
Xenomai userland: libxenomai-dev, libxenomai1, maybe xenomai-runtime
Xenomai kthreads: the above, plus linux-headers--xenomai
RTAI kthreads: linux-headers--rtai, others?

Discussion

  • John Morris

    John Morris - 2014-02-20

    I assume the new debian/configure script is a first attempt made to support buildbot.linuxcnc.org. Thinking about packaging for distros introduces additional questions.

    Most usually, upstream distros package sources from an officially released tarball with a known version and md5sum. I don't see that the LinuxCNC project releases such tarballs, in which case the sources would be created from a git tarball.

    A git tarball of the current ubc3 branch can not be packaged by Debian in 'native' format, at least because it contains no 'debian/control' or 'debian/rules' files. In this case, the Debian package maintainer would need to maintain separate control and rules files as a patch against the upstream tarball. This scenario would make this ticket a non-issue, since the debian/configure file would not be used.

    It seems like a poor idea to commit a default 'debian/control' file because that is a recipe for repeated, accidental commits of the file to git when changed in-place by the debian/configure script.

    So if LCNC project intends that Debian packages come directly from git, the Debian package will be a non-native package.

    The other alternative is for the LCNC project to release tarballs including a debian/control file configured outside of git. This way, the Debian maintainer's job is already done. The control file would only include packages for the three userland flavors, since kthread flavors require linux-headers packages not present in the upstream distros.

    In this case, when it is time to cut a release, the debian/control etc. files could be created with the debian/configure script, which would need to be modified to address the running RT kernel limitation.

    Other than the big distros, I only see the buildbots and official project package releases as consumers of the Debian packaging materials. Are there others who build packages, too? If there are no other toes but our own to step on, then there might not be no point in putting much effort into a general solution.

     

    • Sebastian Kuzminsky

      Sebastian Kuzminsky - 2014-02-20

      The structure of the new debian/configure in ubc3 was designed to enable this use case. The dependencies & recommendations etc are kept in sets, to make overlaps work right. There's a function that adds support for a specified kernel, the -r/-a just passes in the currently running kernel, you should be able to just call it with a list of kernels from the command line.

      For upstream source packages, you're right, we need to run debian/configure locally to build the source package, and upload that. I plan to add a new command-line argument that makes debian/control Build-Depend on all the realtime kernels it can find in the apt package database. We can have one buildslave that just watches the upstream deb archive and another that watches upstream and ours. We'll have to add heuristics to guess the realtime flavor based on kernel version name, since we cant inspect the kernel config.

      --
      Sebastian Kuzminsky

       
      alternate

      • John Morris

        John Morris - 2014-02-21

        Why does the script require that e.g. linux-headers-rt be installed in order to build rtpreempt threads? Kernel headers aren't necessary for any of the userland threads, which is why we can get Xenomai modules into Debian and PREEMPT_RT modules into Ubuntu, despite their lack of those RT kernels in the distro.

        I didn't see your reply 'til just now, and ended up rewriting a bunch of stuff to simplify. I'll point to it once it's in a public git repo.

        Thanks!

         

        • Sebastian Kuzminsky

          Sebastian Kuzminsky - 2014-02-21

          Any erroneous dependencies are the result of my ignorance - please feel free to fix my mistakes.

          Sebastian Kuzminsky

           
          alternate