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

[Nico Kadel-Garcia]

On Thu, May 7, 2015 at 3:56 AM, Vít Ondruch <vondruch at redhat.com> wrote:
> 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.

Stability and clarity help. One of the classic dependencies that gets
mucked up, right now, is 'mysql-libs'', with different MySQL variants
each having their own version of it, with a different name, and
different interwoven dependencies. Another is when there are two
parallel versions of the same component, such as 'samba' and 'samba4'
had for a while.

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

One reason to be more explicit about some of these is backwardsa
compatibility. If a particular ".spec" file is still stable for Fedora
or RHEL releases before the current rpmbuild contained these
particular components, "zip", in particular, is not required by 'mock'
baed rpmbuild environments, but some source bundles are now using it
because of GPG signed git tag exports for source code, rather than
published tarballs. I'm actually fairly horrified by how Red Hat is
publishing their RHEL source code these days, and really wish they'd
switch to using such tags rather then the very funky "read the git
logs and look for the word 'import'" to denote what everyone else in
the world would make a git tag, even a signed git tag these days.