Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 10.0.12
-
Fix Version/s: 10.0.13
-
Component/s: None
-
Labels:None
-
Environment:Linux, Fedora
Description
When building mariadb into some un-ordinary directory like /opt/rh (chroot in Software Collections; see softwarecollections.org for details), we do not want to read system paths like /etc/my.cnf.
However, there are several occurrences in the code, where paths are hard-coded in the source and it makes problems to us when building into some chroot, as mentioned above (reading /etc/my.cnf would be wrong, but we specify correct paths using cmake arguments).
Proposed solutions:
Either these cases (hard-coded paths) should be able to opt-out (using e.g. -DNO_HARD_PATHS=1) or they should be removed entirely, since there is always a configured value used.
Another compromise would be to use the hard-coded paths only when the paths are not specified in the cmake call.
Gliffy Diagrams
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Honza Horak, what is the issue with INFO_SRC and INFO_BIN? What "two packaging commandments" do they break in the docs dir?
Good point, there is a bit different issue with INFO_SRC and INFO_BIN - multilib install. We have moved those two files into /usr/lib(64) because their content is platform specific, which prevented us from installing ix86 and x86_64 RPM packages on one machine. Moving those files to /usr/lib (and /usr/lib64 on x86_64) solves this, so we needed to add a searching path to the test.
Ok to push!
The attached are two related patches we use in Fedora, not heavily tested yet, but we believe it should work in our use cases.
Ideally I'd like to see those (or similar) changes merged into mariadb upstream, but I can understand some compromise will have to be made to stay compatible and not break working deployments.
Any comments welcome.