Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-9111

debian/control has libjudy-dev in Build-Depends

Details

    Description

      The new Debian packaging included in MariaDB 10.1 includes a debian/control file that has a Build-Depends which includes "libjudy-dev". On platforms where there is no libjudy-dev package available (Ubuntu Trusty on ppc64, for example), this means that it's impossible to build the server, even if building without OQGraph (the component that actually requires libjudy-dev).

      Is there a recommended approach for excluding build dependencies when the component with the dependency is not being built?

      Attachments

        Issue Links

          Activity

            It's been discussed before (without much result), but I don't think we had it filed. Assigning to Otto to clarify what we should do about it, since now at least p8 trusty build does not work in buildbot.

            elenst Elena Stepanova added a comment - It's been discussed before (without much result), but I don't think we had it filed. Assigning to Otto to clarify what we should do about it, since now at least p8 trusty build does not work in buildbot.

            If you do manual builds, you can run dpkg-buildpackage -d and the build will proceed even if the required dependencies are not met.

            If you want to customize that certain platforms have different control files, you could do something similar as is already done in the autobake-deb.sh file regarding the libcrypto dependency.

            otto Otto Kekäläinen added a comment - If you do manual builds, you can run dpkg-buildpackage -d and the build will proceed even if the required dependencies are not met. If you want to customize that certain platforms have different control files, you could do something similar as is already done in the autobake-deb.sh file regarding the libcrypto dependency.

            Customizing and maintaining the control file for various different platforms and OSes doesn't sound very attractive. Debian and Ubuntu, and individual versions of each, might very well have different build dependencies, right? Maybe that's less of an issue than I'd expect.

            otto, I'm afraid I don't know what you're referring to with "the libcrypto dependency". I don't see any mention at all of "crypto" anywhere in the debian/ subdirectory of the 10.1 branch.

            Or maybe you're referring instead to libcrack2, where the autobake script does some brute-force apt + sed gymnastics to edit the control file? If that's the recommended approach, then I guess it's the one we'll have to use. It seems like there should be something a lot more flexible than this, though.

            kolbe Kolbe Kegel (Inactive) added a comment - Customizing and maintaining the control file for various different platforms and OSes doesn't sound very attractive. Debian and Ubuntu, and individual versions of each, might very well have different build dependencies, right? Maybe that's less of an issue than I'd expect. otto , I'm afraid I don't know what you're referring to with "the libcrypto dependency". I don't see any mention at all of "crypto" anywhere in the debian/ subdirectory of the 10.1 branch. Or maybe you're referring instead to libcrack2, where the autobake script does some brute-force apt + sed gymnastics to edit the control file? If that's the recommended approach, then I guess it's the one we'll have to use. It seems like there should be something a lot more flexible than this, though.

            MDEV-3809 could be a solution to this (and many other) packaging problems.

            serg Sergei Golubchik added a comment - MDEV-3809 could be a solution to this (and many other) packaging problems.

            kolbe Yes, I meant the libcrack2 hack. That is the easiest way to customize the debian/* contents at build time if there is some exceptions to the packaging, which otherwise very nicely works on all Debian/Ubuntu releases we want to support.

            otto Otto Kekäläinen added a comment - kolbe Yes, I meant the libcrack2 hack. That is the easiest way to customize the debian/* contents at build time if there is some exceptions to the packaging, which otherwise very nicely works on all Debian/Ubuntu releases we want to support.

            serg, I don't disagree with you, but I think otto does not like the idea of using CPack, especially for Debian packaging. Anyway, the discussion about that broader issue can happen elsewhere.

            kolbe Kolbe Kegel (Inactive) added a comment - serg , I don't disagree with you, but I think otto does not like the idea of using CPack, especially for Debian packaging. Anyway, the discussion about that broader issue can happen elsewhere.

            libjudy-dev is available on all relevant platforms and mariadb-10.0 in Debian with libjudy-dev as a build dependency works well: https://buildd.debian.org/status/package.php?p=mariadb-10.0

            otto Otto Kekäläinen added a comment - libjudy-dev is available on all relevant platforms and mariadb-10.0 in Debian with libjudy-dev as a build dependency works well: https://buildd.debian.org/status/package.php?p=mariadb-10.0

            People

              otto Otto Kekäläinen
              kolbe Kolbe Kegel (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.