[MDEV-7066] No Source RPMs ... (and so no "yum-builddep MariaDB-server" either) Created: 2014-11-11  Updated: 2019-03-27  Resolved: 2019-03-27

Status: Closed
Project: MariaDB Server
Component/s: Packaging
Affects Version/s: 5.5, 10.0, 10.1
Fix Version/s: 10.2.24, 10.1.39, 10.3.14

Type: Bug Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: contribution, foundation
Environment:

CentOS, RHEL (all RPM based distributions?)


Issue Links:
PartOf
Relates
relates to MDEV-14954 Build environment information serious... Closed

 Description   

The Knowledge Base article on "why we don't have SRPMs" says:

"We are currently investigating using a source RPM generator as documented via a macro."

< https://mariadb.com/kb/en/mariadb/documentation/getting-started/binary-packages/rpm/why-do-mariadb-rpms-not-include-the-source-rpm-srpms/ >

I couldn't find any related Jira issue though, thus I've now submitted this one.

Reason for this is that I'm missing the ability to say

  yum-builddep MariaDB-server

to pull in all build dependencies required to compile MySQL from source.
I don't even plan to build from SRPMs, but being able to install all required packages in a single step is pretty convenient even when building from source tarballs or directly from bzr / git ...



 Comments   
Comment by Hartmut Holzgraefe [ 2018-01-08 ]

On CentOS 7 this currently has the effect that when following our build environment setup instructions from

https://mariadb.com/kb/en/library/Build_Environment_Setup_for_Linux

you'd actually end up with the build dependencies for MariaDB 5.5 being installed instead of those for current 10.x versions, as CentOS actually provides a source RPM, but still only comes with MariaDB 5.5 by default.

This is even still true whe setting up MariaDB.(org|com) yum repositories. As there's no source RPM to fetch build dependencies from in our repositories yum-builddep will still use the 5.5 source RPM from the CentOS repository

Comment by Daniel Black [ 2018-02-03 ]

https://src.fedoraproject.org/rpms/mariadb/blob/master/f/mariadb.spec used as base for 2 pull requests as attached.

Needed as part of buildbot to generate src.rpm:

cpack -G RPM --config ./CPackSourceConfig.cmake

Comment by Daniel Black [ 2018-02-04 ]

pull requests add Build-Depends unconditionally so a src rpm will (should at least) contain the full list of dependencies for every component of building mariadb. If this is the wrong approach, the conditionals can be used further down the cmake files to where they are accepted/fully enabled.

Comment by Sergey Vojtovich [ 2018-03-13 ]

Overdue PR.

Comment by Sergei Golubchik [ 2018-06-24 ]

danblack, I'll reply here, not in github, ok? Three pull requests, one comment, don't want to copy it in three places.

Two thoughts.
1. Did you actually test your changes? I had so many issues setting CPACK_RPM variables from plugins, and you don't even use PARENT_SCOPE. E.g. this is what I end up having for tokudb:

  GET_DIRECTORY_PROPERTY(V DIRECTORY ${CMAKE_SOURCE_DIR} DEFINITION CPACK_RPM_tokudb-engine_PACKAGE_REQUIRES)
  SET(CPACK_RPM_tokudb-engine_PACKAGE_REQUIRES "${V} jemalloc" PARENT_SCOPE)

2. This seems way too manual. It'll probably be out-of-sync even before we push it. Can we come up with something less fragile?

One way of doing it would be, say, a macro (or function, whatever)

BUILD_REQUIRES(executable_or_library> <rpm build requirement entry>)

To be used like (say, in cracklib plugin)

  CHECK_LIBRARY_EXISTS(crack FascistCheckUser "" HAVE_LIBCRACK)
  BUILD_REQUIRES(crack cracklib-devel)

and in cpack_rpm.cmake or at the end of the main CMakeListst.txt there's a check that verifies that for every FIND_PROGRAM and CHECK_LIBRARY_EXISTS there is a matching BUILD_REQUIRES. Similar to how I do it at the end of plugin.cmake.

Another option would be to replace all FIND_PROGRAM and CHECK_LIBRARY_EXISTS to require a new argument, but the first option looks easier.

Comment by Daniel Black [ 2018-06-27 ]

Ok. Thanks for the review. I like the idea of the macro. I don't remember hitting the scope issues.

Comment by Sergei Golubchik [ 2018-06-29 ]

Here's a new idea, even less intrusive. A patch is worth a thousand words, so the PoC:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8d2efac89cb..ccdb17daf6f 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -490,3 +490,5 @@ IF(NON_DISTRIBUTABLE_WARNING)
   MESSAGE(WARNING "
 You have linked MariaDB with GPLv3 libraries!  You may not distribute the resu>
 ENDIF()
+
+INCLUDE(build_depends)
diff --git a/cmake/build_depends.cmake b/cmake/build_depends.cmake
new file mode 100644
index 00000000000..178f1087980
--- /dev/null
+++ b/cmake/build_depends.cmake
@@ -0,0 +1,22 @@
+MACRO(FIND_DEP V)
+  SET(out ${V}_DEP)
+  IF (NOT ${out})
+    EXECUTE_PROCESS(COMMAND ${ARGN} OUTPUT_VARIABLE O OUTPUT_STRIP_TRAILING_WHITESPACE)
+    SET(${out} ${O} CACHE STRING "Package that contains ${${V}}" FORCE)
+    MESSAGE(STATUS "Need ${O} for ${${V}}")
+  ENDIF()
+ENDMACRO()
+
+GET_CMAKE_PROPERTY(ALL_VARS VARIABLES)
+FOREACH (V ${ALL_VARS})
+  IF (V MATCHES "_(EXECUTABLE|LIBRARY)$" AND ${V} MATCHES "^/")
+    IF (RPM)
+    ELSEIF (DEB)
+    ELSE ()
+      # Test: Gentoo
+      FIND_DEP(${V} equery b -ne ${${V}})
+      SET(BUILD_DEPS ${BUILD_DEPS} ${${V}_PACKAGE})
+    ENDIF ()
+  ENDIF()
+ENDFOREACH()
+LIST(REMOVE_DUPLICATES BUILD_DEPS)

What needs to be done:

  • remove ELSE() # test: Gentoo branch completely.
  • Add rpm (rpm -qf ?) branch (no need to add deb branch, it'll only slow down the build).
  • write down BUILD_DEPS into the specs file
  • test it, may be "_(EXECUTABLE|LIBRARY)$" is not enough
Comment by Sergei Golubchik [ 2018-08-31 ]

Ok, "_(EXECUTABLE|LIBRARY)$" is certainly not enough. It won't detect boost, for example, or any other header-only library. For this one needs to analyze headers, and this is generator-dependent. For example, for Ninja it's something like

ninja -t deps|grep '^    /'|xargs rpm -qf|sort -u

Comment by Sergei Golubchik [ 2019-03-25 ]

source rpm builds work in bb-10.1-serg now. Left to do:

  1. fix buildbot to not try to install .src.rpm in the install step
  2. fix buildbot to put .src.rpm in srpm/ not in rpm/
  3. fix release scripts to put the source rpm where it belongs in a yum repo
  4. update documentation about source rpms for selected distributions, don't forget the jemalloc-devel-static issue
Comment by Sergei Golubchik [ 2019-03-26 ]

1 and 2 are done.

dbart, 3. is on you

Comment by Daniel Black [ 2019-03-27 ]

Nice work serg. Thankyou.

Comment by Daniel Bartholomew [ 2019-03-27 ]

3 is done.

4 is something I'll work with greenman on to make sure it updated documentation is ready for our first release with src.rpm files.

serg: Which release do you expect will be the first one with this?

Comment by Daniel Bartholomew [ 2019-03-27 ]

For the docs, a new Building MariaDB from a src.rpm page will need to be created and this page will need to be updated:

There might be other existing pages that also need to be updated, but this one needs to be updated for sure so that it mentions that some Distributions now have source RPMs available (after they're actually available of course).

Comment by Sergei Golubchik [ 2019-03-27 ]

I'll try to merge it into the upcoming 10.3 release, but if it'll take too long to merge, then the next 10.1.

Generated at Thu Feb 08 07:16:42 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.