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