clime <cl...@fedoraproject.org> writes: > On Sat, 19 Dec 2020 at 20:07, Dan Čermák <dan.cer...@cgc-instruments.com> > wrote: >> >> clime <cl...@fedoraproject.org> writes: >> >> > On Thu, 17 Dec 2020 at 22:04, James Szinger <jszin...@gmail.com> wrote: >> >> >> >> On Thu, 17 Dec 2020 14:05:40 -0500 >> >> Ben Cotton <bcot...@redhat.com> wrote: >> >> >> >> 1. How does this affect users who download, maybe modify, and rebuild >> >> the SRPM? Can they continue to use rpmbuid and mock as they have >> >> been? Does the SRPM contain the pre-processed or post-processed spec >> >> file? >> > >> > They can use mock if the preprocessing will be enabled for the >> > respective chroots where it is enabled in Koji/Fedora. >> > They can't directly use rpmbuild for those packages that contain the >> > macros. But they can use rpkg/fedpkg to do the work. >> > Or preprocess spec first and then use rpmbuild. I am aware this is a >> > negative point of this change. >> >> This is a pretty big downside imho, as that means that building Fedora >> packages that use these new kinds of macros in other build systems will >> become impossible or at the very least, very, very difficult. There is >> quite some development going on in OBS (afaik e.g. Igor exported all >> Fedora Rust rpms to OBS for automated rebuilds) and enabling this >> preprocessing will make these packages FTBFS in OBS. >> > > It depends on how the srpms are being built and if Fedora DistGit is > used directly as the source (as Adam has said also). If there is such > a possible breakage, we can look at fixing it in advance. > > The tooling that implements preprocessing has minimal requirements > (git or git-core, bash, python, libgit2-devel, rpm-devel) so there > should be a very low barrier for entry for any environment that would > need it. > >> Don't get me wrong, I am not opposed to this proposal per-se. But as far >> as I recall, many people were pretty upset about modular packages being >> effectively only buildable in Fedora's infra and nowhere else. And I'd >> very much like not to repeat this. >> >> > While having an option to use rpmbuild directly to build srpm/rpm from >> > a dist-git repo is nice, I would say that fedpkg or mock are the main >> > interfaces to do this. >> > I know this answer won't satisfy everyone. >> >> Indeed. I think there *should* be at least a way how to produce a srpm >> that can be rebuild *without* having access to Koji, mock and fedpkg >> (ideally by our own infrastructure). > > Well, that excludes lots of options already :). One can also use > preproc-rpmspec tool to get a rendered spec file (this is what mock > uses). > > $ preproc-rpmspec pkg.spec.rpkg # prints rendered spec to stdout, > pkg.spec.rpkg is a spec template
This would be a viable workaround, but a workaround nevertheless. Since I am not frequently rebuilding Fedora rpms outside of mock, koji & copr, I cannot tell how much of a show-stopper that is though. At least I think that the benefits of the change need to be pretty big to outweigh this potential downside. Cheers, Dan
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
