The current guidelines have a section at https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 which attempts to define the current buildroot. It is probably out of date, and FPC really shouldn't be in the business of either defining or having to keep up with what is in the minimal build environment. It is far simpler for us to say that you should specify your dependencies completely and then let releng and the other committees (or just RPM's dependency list) decide what actually gets installed.
I propose to clean up that section significantly by simply removing both the rpm-rpmdevelrpms section section and the Exceptions section. Replace these with some text indicating the use of the BuildRequires: tag, information on testing with mock or koji and why this is important, and the big one:
Indicating that packagers should assume that nothing is present beyond what is required to have rpm actually work, process the spec, unpack the tarballs and run the scripts which make up the sections.
If it would be helpful, we can vote on the removal of the rpm-rpmdevelrpms section separately. I can't conceive of what relevance it has these days, and the long pre block is just pointless.
A draft is at: https://fedoraproject.org/wiki/User:Tibbs/BuildReqDraft Diff from the original is at https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FBuildReqDraft&diff=402259&oldid=402253
The draft is good. The key sentence is:
You may assume that you have everything necessary for RPM to function and process your spec file (so of course RPM is present, along with redhat-rpm-config and what is necessary for rpm to apply patches, unpack archives, and run the shell scripts which make up the spec file sections.)
While this is a simple statement, it still arises some questions:
If my source package has sources compressed with a ''foo'' method, how can I be sure the rpmbuild and its macros can unpack it?
And if they cannot, which party is responsible for declaring the dependency (my source package to build-require ''foo'', or rpmbuild to run-require ''foo'')?
I think that either the guidelines should list guaranteed abilities of the rpmbuild, or it should point to place where a packager can obtain the data. We have experience with rpm not being documented properly. (Do you remember the new dependency filters?)
This is very important question because it nails down the matter of the whole discussion leading to this FPC ticket.
I hope the answer is no. Otherwise it would again make the question of transitive dependencies uncertain.
Might want to send a note about this one out to the mailing list. The BuildRequires exceptions is a very old thing. It was carried over from fedora.us. I remember discussing and reapproving it in the first FPC (with jkeating and scop and so on). I think the people who didn't want to list BuildRequires that were "too common" would probably be present on the mailing list if they're still active in Fedora.
I remember discussing it as well. And I'm all for spec file simplification, really, but I just don't want FPC to be in the business of deciding this. And yes, this should go to the lists, but it might be nice to hash it out here a bit first in order to minimize pointless invective.
This issue has come at FPC from two different directions (one about gcc, the other about perl) neither of which are really our concern, and I think the best thing for us would be to get out of it. I'm happy to throw in a "should" and basically say "if it builds, you're OK, but if releng changes something and it doesn't build then shame on you for not completely specifying things". Or, from another angle, releng or the rpm packager or whatever can change the dep tree as it sees fit and know that the guidelines don't have to change to accommodate that.
As to ppisar's questions:
For the first two, how can you tell now that rpmbuild can unpack your tarball? Honestly, I don't know anything besides the obvious answer: you build it in mock and see what happens. I do not think my proposal has any bearing at all on those two questions, though I'd be happy to change "unpack archives" to something a bit more vague ("unpack the majority of archive types", maybe). Are there any packages that need to unpack, say, a .cab archive? It should be pretty obvious to everyone that you're going to need a dependency on cabextract. Maybe "unpack any archive the %setup or %autosetup macros understand" and punt to some other documentation.
Really I don't think this is such a big deal in any case; this doesn't need to be made so legalized that we need a contract lawyer to write it.
For the third question, I don't know. What if rpm decides to internalize the %patch code and not shell out to /usr/bin/patch? I guess it could, but my question is about as esoteric as yours. Again it's kind of one of those things that really matters only if someone's going to try and play lawyer.
I think a somewhat analogous issue arises with %autosetup and its automatic SCM thing, where you're expected to make sure to have a build dependency on the SCM that you ask %autosetup to use. I think that rpm could conceivably do more of that and I'd rather just specify the minimum pretty much as I have in my proposal.
All of that nonwithstanding, I recognize that what I've written doesn't, for example, tell you that you even have coreutils. And even if it did specify that, coreutils could conceivably split out something less-used in order to save dependencies. So I recognize that we can never specify this exactly in the guidelines, and err on the side of simplicity. Otherwise we get back to something like what we had, which will get out of date eventually and we'll be back here again in five years.
No please, do not make the sentence more vague. Making things vague when one desires for guidelines is not helpful.
If FPC does not want to bless any of the ideas (''you can rely on transitive dependencies'' versus ''you need to specify all direct dependencies''), then it's better to not put anything about it into the guidelines.
Just be prepared that once you remove the build-requires exception list, then the question will materialize in its purity and loudly discussion will follow. Maybe it's good approach: Rather then writing some guidelines out of blue, let crowd to find proper solution and then write it down.
To sum it up, if you want only to remove the build-require exception list, then the draft is good enough.
This was discussed in this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-02-05/fpc.2015-02-05-17.02.txt):
...note that the rest of the policy changes will be looked at in the future.
I went ahead and removed the section. As for the rest of this issue, I'll bring it to the packaging list after the weekend (because I'm going out of town and won't be able to participate in any discussion).
Thanks.
I regenerated my draft from the updated BuildRequires section; it can be found at https://fedoraproject.org/wiki/User:Tibbs/BuildReqDraft2. Diff from the current guidelines is at https://fedoraproject.org/w/index.php?title=User%3ATibbs%2FBuildReqDraft2&diff=403803&oldid=403802
Discussion started on the packaging list: https://lists.fedoraproject.org/pipermail/packaging/2015-February/010466.html
If there's not sufficient traffic there, I'll take it to devel.
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-02-19/fpc.2015-02-19-17.00.txt):
Ping for tibbs, going to put in needinfo.
This is entirely my fail. Will try to look at this soon.
After internalizing the few comments I received on the packaging list, I cut the draft down all the way to this paragraph:
It is important that your package list all necessary build dependencies using the BuildRequires: tag. You may assume that enough of an environment exists for RPM to function and execute basic shell scripts, but you should not assume any other packages are present as RPM dependencies and anything brought into the buildroot by the build system may change over time.
I'm trying to get get right to the edge of saying "you have a shell and coreutils".
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-05-14/fpc.2015-05-14-16.01.txt):
note that this was for comment 16, and not the linked draft.
Announcement text:
The BuildRequires section of the guidelines has been revised; the exceptions list is gone. The release engineering folks are free to define the buildroot and rpm is free to change its dependency list. * https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRequires_2 * https://fedoraproject.org/w/index.php?title=Packaging%3AGuidelines&diff=413629&oldid=409506 * https://fedorahosted.org/fpc/ticket/497
Metadata Update from @tibbs: - Issue assigned to tibbs
Login to comment on this ticket.