Bug 227790
| Summary: | Declaring subpackages to be noarch causes debuginfo files to not get packaged | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Guthrie <mathguthrie> | ||||||||||
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> | ||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | |||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | medium | ||||||||||||
| Version: | 6 | CC: | triage | ||||||||||
| Target Milestone: | --- | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| Whiteboard: | bzcl34nup | ||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2008-04-12 09:45:38 UTC | Type: | --- | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Embargoed: | |||||||||||||
| Attachments: |
|
||||||||||||
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
"noarch".)
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
files.
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 sub-package. 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 ;-) WONTFIX 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 changed. 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. Jeff, 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 pnasrat'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. http://fedoraproject.org/wiki/LifeCycle/EOL 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 the change. 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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 |
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: /usr/lib/debug/usr/sbin/apcaccess.debug /usr/lib/debug/usr/sbin/apctest.debug ... [ 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): 4.4.2-32 How reproducible: Every time 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 file. 3.Add the tag "BuildArch: noarch" immediately below the summary for the subpackage. 4.run "rpmbuild -bb" on the .spec file. Actual results: rpmbuild errors out by saying that all of the debuginfo files are unpackaged. Expected results: 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". Additional info: I will be attaching spec files and output in my next post.