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(a)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