Build: Increase build dependencies for 3.1.0. - #4142
Conversation
|
@nrwahl2 I think you'll like this one. |
|
@clumens Some, possibly all, of the CI failures are due to what we agreed we're okay with: the older OS releases in CI don't have the required package versions. We'd need to work with Fabio and Chrissie on that. |
Yep, I figured that would happen. I wanted to get an ACK on doing this first, and then I'll talk to them about what needs to be done (I assume on Monday or Tuesday, given the holidays), and then once CI is ready I'll merge it. |
nrwahl2
left a comment
There was a problem hiding this comment.
This basically looks good to me. A few comments.
| Requires: %{pkgname_bzip2_devel}%{?_isa} | ||
| Requires: corosync-devel >= 2.0.0 | ||
| Requires: corosync-devel >= 3.1.9 | ||
| Requires: glib2-devel%{?_isa} |
There was a problem hiding this comment.
The version checking is inconsistent -- which is not a new issue. I don't know why we don't have version requirements here for some of the packages, like glib2-devel. Similarly, we check for some things (e.g., the corosync version) in the spec file but not in configure.ac.
There was a problem hiding this comment.
I can add an additional patch that adds version requirements on things that don't currently have them but are mentioned in INSTALL.md or configure.ac. For everything else, I assume the exact version just does not matter to us.
| | documentation | | python3-sphinx | python3-sphinx | python3-sphinx | | ||
| | documentation (PDF) | | latexmk texlive texlive-capt-of texlive-collection-xetex texlive-fncychap texlive-framed texlive-multirow texlive-needspace texlive-tabulary texlive-titlesec texlive-threeparttable texlive-upquote texlive-wrapfig texlive-xetex | texlive texlive-latex | texlive texlive-latex-extra | | ||
| | annotated source code as HTML via "make global" | | global | global | global | | ||
| | RPM packages via "make rpm" | 4.19.1 or later | rpm | rpm | (n/a) | |
There was a problem hiding this comment.
We don't appear to enforce this one anywhere either
There was a problem hiding this comment.
No, and I don't think we're really supposed to. I think it's generally considered better form in the spec file to conditionalize on the OS version or test that a macro is present before using it.
The bump in the gettext requirement in particular silences a lot of warnings I've been seeing for years when running ./autogen.sh. Fixes T1021
Fixes T1021