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

MariaDB should include files like MySQL's docs/INFO_{SRC,BIN}

Details

    • Task
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Won't Fix
    • N/A
    • Packaging
    • None
    • 10.2.0-6, 10.2.0-7

    Description

      Oracle MySQL distributions include the files INFO_BIN and INFO_SRC in a "docs" subdirectory of tarball packages. These files show the revision number of the source tree when the build was created, the cmake options used to create the build, etc. I'm not sure whether these are created automatically when "cmake" is executed, or if maybe they're done manually using some other part of a build process.

      But they're very useful, and it would be really nice for something like this to be included with MariaDB.

      Attachments

        Issue Links

          is caused by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-6526 INFO_SRC and INFO_BIN installed wrong

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12211 Testsuite: file_contents.test and packaging should be updated for Red Hat distributions

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            wlad Vladislav Vaintroub added a comment -

            I actually vote against this feature. INFO_* was created by someone who had only vague idea of CMake, with the purpose of learning cmake. The result is bad, the targets are always outdated. That piece of work, imo, should be removed.

            For releases, revision corresponds to the git tag. CMake options are -DBUILD_CONFIG=mysql_release. If someone is really interested, which is hopefully not the case, then we should probably include the whole CMakeCache.txt, it has all the options.

            wlad Vladislav Vaintroub added a comment - I actually vote against this feature. INFO_* was created by someone who had only vague idea of CMake, with the purpose of learning cmake. The result is bad, the targets are always outdated. That piece of work, imo, should be removed. For releases, revision corresponds to the git tag. CMake options are -DBUILD_CONFIG=mysql_release. If someone is really interested, which is hopefully not the case, then we should probably include the whole CMakeCache.txt, it has all the options.
            kolbe Kolbe Kegel (Inactive) added a comment -

            I have no interest in reproducing the exact INFO_SRC/INFO_BIN files ... "something like this" would be fine

            The problem is not so much for releases, it's for custom or hotfix builds or builds created by customers or other users. It's important to be able to tell after-the-fact what actually was built, what options were used, and where it came from.

            Even CMakeCache.txt won't say exactly what commit or branch something was built from, which is pretty important in trying to reproduce problems. And I think CMakeCache.txt also doesn't show which things were specified on the command line instead of being inferred or inherited from the environment, but I may be wrong about that.

            kolbe Kolbe Kegel (Inactive) added a comment - I have no interest in reproducing the exact INFO_SRC/INFO_BIN files ... "something like this" would be fine The problem is not so much for releases, it's for custom or hotfix builds or builds created by customers or other users. It's important to be able to tell after-the-fact what actually was built, what options were used, and where it came from. Even CMakeCache.txt won't say exactly what commit or branch something was built from, which is pretty important in trying to reproduce problems. And I think CMakeCache.txt also doesn't show which things were specified on the command line instead of being inferred or inherited from the environment, but I may be wrong about that.
            wlad Vladislav Vaintroub added a comment -

            If it is not so much for releases, but for custom builds, why the request to package them in our tarbin?
            To cmake command line -there is no way to know the exact command line, even if if INFO_* pretends to know . cmake does not provide this functionality.

            wlad Vladislav Vaintroub added a comment - If it is not so much for releases, but for custom builds, why the request to package them in our tarbin? To cmake command line -there is no way to know the exact command line, even if if INFO_* pretends to know . cmake does not provide this functionality.
            kolbe Kolbe Kegel (Inactive) added a comment -

            There have been specific cases where customers are given "custom builds" that are produced by buildbot. Those don't come with any information about the specific commit they're built from, which makes it nearly impossible to reliably identify what is actually being used.

            My request is that as much of this information as possible be included, by default, in any builds done from our source. That means that someone will get access to this important information no matter where the package they're using has come from.

            I want to know the name of the source tree, the name of the branch, the commit, how CMake is invoked, what CMake finds and ultimately uses for the build, etc. It may be some or all of that is not feasible for any number of reasons. But perhaps some of it is?

            kolbe Kolbe Kegel (Inactive) added a comment - There have been specific cases where customers are given "custom builds" that are produced by buildbot. Those don't come with any information about the specific commit they're built from, which makes it nearly impossible to reliably identify what is actually being used. My request is that as much of this information as possible be included, by default, in any builds done from our source. That means that someone will get access to this important information no matter where the package they're using has come from. I want to know the name of the source tree, the name of the branch, the commit, how CMake is invoked, what CMake finds and ultimately uses for the build, etc. It may be some or all of that is not feasible for any number of reasons. But perhaps some of it is?

            People

              serg Sergei Golubchik
              kolbe Kolbe Kegel (Inactive)
              Votes:
              1 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.