On Thu, 17 Dec 2020 at 21:23, Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > On 12/17/20 8:05 PM, Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing > > > > > > == Summary == > > This change should enable an opt-in spec file preprocessor in Fedora > > infrastructure for the benefit of packagers. The preprocessor allows > > some very neat tricks that were impossible before, for example > > generate changelog and release automatically from git metadata or pack > > the entire dist-git repository into an rpm-source tarball (effectively > > allowing unpacked repos to live in DistGit). > ... > > I'd very much like to understand the impact of this on the following: > > > 1) Provenpackagers doing mass spec changes/updates. If the mass spec change/update doesn't involve an rpkg macro, then there is no difference. If it does involve an rpkg macro, then we should directly change the macro so that the spec file gets rendered correctly according to the latest state-of-art. That probably means notifying affected packagers first but for a proven packager it is less work. There is also an option that a packager would specify the macros version with which to evaluate the spec file in `rpkg.conf` file. In that case, he would need to bump that version first so that the updated macro gets used. Not sure if something like this would be needed but this would prevent any changes in spec file unless the packager wants them on his/her own. > > 2) Provenpackagers and/or RelEngs doing (targeted) mass rebuilds. There should be no impact here. If the source git repo stays the same, then the same srpm as for a previous build will be produced. > > 3) Packagers doing `fedpkg local` builds. This PR makes sure `fedpkg local` will work: https://pagure.io/rpkg/pull-request/530 if preprocessing is enabled. There is a bit of additional work to open a PR for fedpkg to parse rpkg.conf file if it is present in a dist-git repo and enable preprocessing if it is enabled there in the file. It's just a few lines that I plan to write when I get feedback on the `rpkg` pull request. > > 5) Our downstreams rebuilding from dist-git. If they use mock or fedpkg, there should be no impact. If they use bare rpmbuild, it will no longer work and some changes will be needed. > > 4) Packages needed to be installed in buildSRPMFromSCM mock and/or Koji host. I am not sure if I understand correctly here so maybe this will need some more explanation. But the preprocessing needs some additional tooling to get installed that I tried to minimize. Basically: preproc, rpkg-macros, rpm-git-tag-sort, libgit2, git-core are the main packages needed to run the preprocessing. These packages get installed into the target chroot where the srpm is also built afterwards. They are installed only if preprocessing is enabled. > > > I'd also like to know, where exactly is the spec file pre-processed. Is it in > the buildSRPMFromSCM mock, or on the Koji host? It is preprocessed in the target chroot, i.e. in the same environment where rpmbuild -bs is called afterwards. > > > It feels like this will open a can of worms and I don't think the benefits are > worth it. IMHO we should strive to make RPM specs more flexible instead of > adding another layer on top of it. But I admit that I don't have all the > information yet. I think something like this is needed whether it is in rpm or in rpkg/mock. I think having implemented it on an upper layer than rpm is not such a huge deal. > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx