TL;DR: There's a proposal for nuking the list of BuildRequires exceptions from the packaging guidelines. Important note: this is just an idea. We're not currently changing the guidelines based on this. Nothing is set in stone. It may end up that nothing happens. Don't panic. A couple of times recently, people have floated proposals to the FPC about removing certain things from the buildroot. (Specifically, perl and gcc*.) And the bottom line for these is that while FPC tries to maintain a list of BuildRequires: exceptions, this is really up to releng and whatever rpm happens to pull in at any particular time. This means that whatever list FPC maintains, it's going to get outdated eventually, and giving packagers the idea that they don't have to actually specify all of their dependencies restricts what releng can do and, perhaps, what dependencies the RPM package can drop without breaking builds. So, the generally stated proposal: I would like to get FPC out of the business of specifying this list of exceptions, and instead just indicate that packagers should completely specify their dependencies. My specific proposal can be seen in https://fedorahosted.org/fpc/ticket/497; the draft is at https://fedoraproject.org/wiki/User:Tibbs/BuildReqDraft2. You can use the history tab to see the differences between that and the current guidelines. Now, the real issue is in what packagers can depend upon. Obviously you have RPM and an environment necessary to build a package (which means you have to have a shell to execute the scripts that make up the RPM sections, and redhat-rpm-config, and whatever RPM happens to use to execute %patch, which I guess could be some internal library if the RPM devs wanted). But what else? That's the open question. The draft currently says: --- 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.) 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. --- Honestly, I'm not completely satisfied with that but I can't come up with anything better. Polite discussion is welcomed and encouraged. - J< -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
