Red Hat Bugzilla – Bug 227790
Declaring subpackages to be noarch causes debuginfo files to not get packaged
Last modified: 2008-04-12 05:45:38 EDT
Description of problem:
Suppose you have a package that generates debuginfo files. If you add into the
.spec file for that package a subpackage that you declare as "noarch", then when
you run rpmbuild on that .spec file, it will generate the debuginfo file in the
/usr/src/debug and /usr/lib/debug directories as expected, but it will not
package them. Instead, one gets an error of the form:
RPM build errors:
Installed (but unpackaged) file(s) found:
[ very long list snipped ]
(This was output from an apcupd .spec file that I had lying around to test this.)
Why would one want to do this in the first place. Well, suppose you have a
large *-docs subpackage that consists only of html files. That would clearly be
an architecture-independent package. (Although I guess the meaning of "noarch"
is currently up for debate.) One could conceivably want to declare that
subpackage as "noarch" and leave the main package as "i386" or "ppc" or whatever.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Find a package that has corresponding debuginfo files
2.Edit the spec file to include a dummy subpackage that contains a single empty
3.Add the tag "BuildArch: noarch" immediately below the summary for the subpackage.
4.run "rpmbuild -bb" on the .spec file.
rpmbuild errors out by saying that all of the debuginfo files are unpackaged.
I would expect to get a main package with its corresponding debuginfo subpackage
with whatever architecture they are supposed to have, and I would also expect
to get a subpackage of type "noarch".
I will be attaching spec files and output in my next post.
Created attachment 147629 [details]
Normal apcupsd.spec file
This is an fc3 apcupsd.spec that I found lying around with all of its
components. I am attaching this and its output for comparison purposes.
Created attachment 147630 [details]
output of rpmbuild -bb apcupsd.spec
This is the output of running "rpmbuild -bb apcupsd.spec". Everything in this
is normal and expected.
Created attachment 147631 [details]
apcupsd.spec file with dummy "noarch" subpackage
Here is a modified version of the last spec file. Note the additional
subpackage "apcupsd-sub", and how it has the additional "BuildArch:noarch" tag
for the subpackage, but not the main package. The subpackage consists of a
single file that contains the string "apc". (Hence, would be a candidate for
Created attachment 147632 [details]
output of rpmbuild -bb apcupsd.noarch.spec
This is the output of "rpmbuild -bb apcupsd.noarch.spec". Note that
immediately after the %install section, it runs find-debuginfo.sh as one would
expect. At the end it gives a long list of all of the debuginfo files as being
unpackaged. I would have expected that these would have been packaged into a
debuginfo rpm since it was rpmbuild, not me or my spec file that created those
AFAIK, it is a feature of RPM that you cannot change the buildarch
of sub-packages. You have only a single spec file for an arbitrary
number of sub-packages, a single %build section for all of them.
Imagine somebody would sneak arch-specific builds into a noarch
I was wondering if that was the case. But if so, I would expect that rpmbuild
would fail with an explicit error message stating that subpackages have to have
the same buildarch as the main package. Instead, rpmbuild uses resources to
generate debuginfo files, and then just fails to package them. That seems to be
kind of a cryptic way to indicate an potential error in the spec file. To me
that indicates something "interesting" is going on in the rpmbuild logic.
Namely, it sees the files in the main non-noarch package that are "debugable",
so it generates debuginfo files. But then the noarch in the subpackage causes
it to not generate the .spec template for the debuginfo files. (This is, of
course, just speculation.)
I should also point out that I haven't been able to find any restrictions on the
use of BuildArch in subpackages in any of the documentation that I have looked a
(In which case, this might be a bug in the documentation. Or I just might not
have looked at the correct documentation. ;-)
There are restrictions. rpm has only a sinngle build and there is only one arch during that build.
So there are no noarch subpkgs, just like there is no Santa Claus ;-)
I think you misunderstood what I said earlier. I now understand
that one can't have noarch subpkgs. (I tried to communicate that
understanding in comment #6.) I'm not asking for that to be
However I do consider the current behavior a bug. If one is not
supposed to put a BuildArch: tag in a subpackage definition, then
why doesn't rpmbuild just display an error message and refuse to
do anything? I would consider that to be a much more acceptable
behavior than going through an entire build, and then saying that
files that rpmbuild put there can't be packaged. I'm open to
arguments as to why that isn't a bug either.
An alternative would be some kind of documentation of this
restriction someplace. I was not able to find any such
restriction in Maximum RPM or in the GURU LABS RPM GUIDE. (Both
of which are on rpm.org.)
And perhaps this is more appropriate in a venue such as the
rpm-devel mailing list.
I don't disagree, and you're not the first to expect noarch subpackages.
Meanwhile, rpm ahs always had only a single build, and the intent has always
been that arch be contant valued throughout the single build. "Unable to find"
any info in Max-RPM and GURU labs does not imply anything at all no matter
where the bits are stored.
Meanwhile, rpmbuild has always been "best effort" in the sense that the build proceeds
as far as possible in spite of other errors. A "best effort" approach is more efficient because it finds
more than just the next error. "Best effort" means that other helper scripts will be run even though
the build is ultimately going to fail to produce binary packages.
And yes, there is acascade effect for error with "best effort" proceeding in spite of known
errors. Find the first error, fix, squint the other errors looking for other fixes, lather rinse repeat.
That is "best effort" in a nut-shell.
Thank you very much for the explanation. I guess I was thinking more
in terms of a "make"-model than a "gcc"-model. If rpmbuild is
"best-effort", then the behavior certainly makes sense. If, as you say,
I'm not the first person to ask about this issue, that would suggest
to me that it should be documented someplace. But that is an argument
for elsewhere than here. (Of course, the "bug" could be that I was
reading incomplete sets of documentation. If there are more complete
sets of documentation than what I cited above, I would love to know.)
Documenting procedures, particularly filing procedures, is kinda hard: the universe
of failures is always larger than the universes of successes.
You're not the first to person to ask for the ability to produce noarch subpackages.
The confusion comes from a single build producing multiple sub-packages, one
expects the attribute of "noarch" to be associated with the packages, not the build.
But a build for "noarch" is likely very different than a build for a specific arch, and
identifying all possibles uses of an arch attribute and determining the appropriate
arch attribute is practically impossible.
The "Red Hat RPM Guide" is recent and complete, the original "Maximum RPM" has
been updated. There are other "RPM Howto Guides" including that by Guru Labs.
hmm, that should have been "failing" not "filing" apologies for the typo.
User email@example.com's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers