On Sat, 19 Dec 2020 at 20:57, clime <clime@xxxxxxxxxxxxxxxxx> wrote: > > On Sat, 19 Dec 2020 at 20:07, Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote: > > > > clime <clime@xxxxxxxxxxxxxxxxx> writes: > > > > > On Thu, 17 Dec 2020 at 22:04, James Szinger <jszinger@xxxxxxxxx> wrote: > > >> > > >> On Thu, 17 Dec 2020 14:05:40 -0500 > > >> Ben Cotton <bcotton@xxxxxxxxxx> 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, also once you produce an srpm, it will be just a generic srpm that can be rebuilt in any rpm-compatible system. > 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 > > > > > > > Cheers, > > > > Dan _______________________________________________ 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
