[Fedora-packaging] Proposal: Remove BuildRequires: exceptions from the guidelines

[Ralf Corsepius]

On 05/07/2015 09:21 AM, Vít Ondruch wrote:
> Dne 6.5.2015 v 19:48 Ralf Corsepius napsal(a):
>> On 05/06/2015 07:12 PM, Jason L Tibbitts III wrote:
>>>>>>>> "VO" == Vít Ondruch <vondruch at redhat.com> writes:
>>>
>>> VO> # dnf repoquery --disablerepo=* --enablerepo=rawhide --requires
>>> rpm-build
>>>
>>> Those dependencies could change at any time.  I would like for them to
>>> be able to change without the guidelines having to change with them.
>>> Obviously any change would break some package somewhere, but at least it
>>> would get one committee out of the process.
>>
>> As much as I welcome this effort, I think we need a detailed and fixed
>> per-fedora-release package list, to be able to give packagers some
>> helpful guidance.
>>
>> That said, why can't we have a link to the list being used by mock
>> (The packages being listed in mock's "buildsys-build") inside the FPG?
>>
>
> What would be the point of link to comps when most of the dependencies
> are defined by rpm-build package?

With the FPG being changed to the proposal, I am expecting
- length discussions (esp. in reviews) about whether tools "x" is 
guaranteed to be present in build-roots: "Is touch, ls, zip, etc. in 
build-root or not? (Been there, seen that many times :) )

- broken builds, because vanishing implicit BR's can trigger different 
sets of build conditions and thus break packages.
(Bugs/discussions along the lines package A in fcX had "feature A", 
fcX+1 lacks it).


> Actually, the buildsys-build should
> contain just rpm-build and nothing more (or it could be abandoned
> entirely, since it would loose its purpose this way).
I do not consider this to be workable, because rpm-build's deps are just 
arbitrary requirements and _not_ a well defined fundation of tools.

That said, I do not consider "rpm-build" to be something to be featured.

Instead, we need an explict well defined set of tools which are 
guaranteed to be present throughout the life-time of a release.

Implementation-wise, this could be implemented as explict BRs of 
rpm-build, an independent package or a package group.
IMO, the appropriate party to define this set of packages is those 
people who define the set of packages in mock.

> Moreover, if the buildsys-build contains components which are already
> required by rpm-build, they should be cleaned up immediately. I am
> speaking about bzip2, gzip, tar, xz, sed, patch, grep, gawk, findutils,
> diffutils, cpio, bash, these are all duplicated.
IMO, here, you are repeating my reasoning above in different words: 
rpm-build's deps are arbitrary.


Ralf