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

[Vít Ondruch]

Dne 7.5.2015 v 09:48 Ralf Corsepius napsal(a):
> 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 :) )
>

No guarantee is the best guarantee.

> - 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).

You pretend like this does not happen on any level just a bit deeper
then what is defined by buildsys-build or rpm-build. But the bad news is
that it happens anywhere any time.

>
>
>> 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.
>

As well as any defined group is arbitrary. We have probably disagree here.


Vít