clime <clime(a)fedoraproject.org> writes:
On Sat, 19 Dec 2020 at 20:07, Dan Čermák
<dan.cermak(a)cgc-instruments.com> wrote:
>
> clime <clime(a)fedoraproject.org> writes:
>
> > On Thu, 17 Dec 2020 at 22:04, James Szinger <jszinger(a)gmail.com> wrote:
> >>
> >> On Thu, 17 Dec 2020 14:05:40 -0500
> >> Ben Cotton <bcotton(a)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