On 31. 03. 21 21:52, Ben Cotton wrote:
* Strict checking for unpackaged content in builds
...
* Many existing packages will fail to build due to the stricter
buildroot content checking. Fixing this in the packaging is always
backwards compatible. We could temporarily set
`%_unpackaged_files_terminate_build 0` in rawhide to alleviate initial
impact if necessary.
This is my main concern with this update.
tl;dr If you %exclude something and there is no other subpackage to own the
files, the build fails:
This fails:
%install
...
touch %{buildroot}/foo %{buildroot}/bar
%files
/
%exclude /foo
This still succeeds:
%files
/
%exclude /foo
%files foo
/foo
Many packages do the former in Fedora for various different reasons, namely to,
well... exclude files from the package (and not ship them at all). Sometimes a
`rm` in %install can be used instead. Sometimes not, because the files are
needed in the %{buildroot} for %check but not needed to be shipped.
When this change was introduced upstream in November 2020, I've analyzed the
impact on Fedora packages. Bare in mind that the data is 4+ months old.
https://github.com/rpm-software-management/rpm/pull/1442#issuecomment-731...
- 1675 packages had %exclude in the spec file
- 261 packages FTBFS for unrelated reason (incl. a very limited timeout)
- 1414 packages actually tested
- 537 packages built successfully, that is ~38%
- 877 packages failed with unpackaged files, that is ~62%, list attached
When I extrapolate the numbers to compensate the unrelated FTBFS, that's likely
more than 1000 affected Fedora packages.
OTOH ~500 packages are generated rubygem-* packages, automatically fixable.
I'd like to know how are the affected packages supposed to migrate to RPM 4.17
behavior, especially if they cannot remove the files in %install prior to
%check. Are they supposed to remove the files at the end of %check instead? What
if the package is build without %check?
Using `%_unpackaged_files_terminate_build 0` in entire rawhide just to
compensate this:
- is dangerous for other implications of the setting
- only postpones the problem to a later time (when we will face the same issue)
And for a more specific problem, around ~100 Python packages were affected when
tested, many of them crucial (e.g. dnf), so this problem will block the upgrade
to Python 3.10 if the change lands in Rawhide before we upgrade Python (which is
the current plan) until we fix all the affected packages (by at least adding
`%global _unpackaged_files_terminate_build 0` to them, which is a tad big
hammer, but it will be our last-resort option).
List of affected Python packages:
https://pagure.io/releng/issue/10072#comment-724315
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok