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@xxxxxxxxxx> 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 -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
