Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Won't Fix
-
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
-
MDEV-6526 INFO_SRC and INFO_BIN installed wrong
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Workflow | MariaDB v2 [ 59640 ] | MariaDB v3 [ 63101 ] |
| Fix Version/s | 10.2 [ 14601 ] |
| Sprint | 10.2.0-1 [ 21 ] |
| Rank | Ranked lower |
| Assignee | Sergey Vojtovich [ svoj ] |
| Sprint | 10.2.0-1 [ 21 ] | 10.2.0-1, 5.5.47-1 [ 21, 22 ] |
| Rank | Ranked higher |
| Sprint | 10.2.0-1, 5.5.47-1 [ 21, 22 ] | 10.2.0-1 [ 21 ] |
| Rank | Ranked lower |
| Sprint | 10.2.0-1 [ 21 ] | 10.2.0-6 [ 37 ] |
| Sprint | 10.2.0-6 [ 37 ] | 10.2.0-6, 10.2.0-7 [ 37, 39 ] |
| Rank | Ranked lower |
| Link |
This issue relates to |
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.
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.
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?
| Assignee | Sergey Vojtovich [ svoj ] |
| Component/s | Packaging [ 10700 ] | |
| Fix Version/s | N/A [ 14700 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
| Assignee | Sergei Golubchik [ serg ] |
| Workflow | MariaDB v3 [ 63101 ] | MariaDB v4 [ 132518 ] |
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.