On Wed, Jan 27, 2021, at 11:50 AM, Vít Ondruch wrote:
You can do this in mock without messing with your system. You can use
`mock -i some.rpm`, you can even use `mock --pm-cmd whatever dnf
command you want to use`. You can use `mock your.srpm
--short-circuit=install` and similar. You can use `mock shell --unpriv`
if you want to tinker more. Mock is everything you ever wanted to
develop for Fedora.
So could you please share with us specifics of your workflow which
makes it unique and which really requires `fedpkg local`? I can't
imaging that intentionally breaking the host system due to testing
soname bump is the right thing to do.
Personally I spend 95% of my time inside an unprivileged pet "toolbox" style
container with podman; I very very rarely execute any commands on the "host"
context.
And mock doesn't really nest well (nested containers in general are possible but still
involve some tricky compromises).
So I use `fedpkg local` a lot, and I also often install these packages into my dev
container *or* I just skip RPM entirely and `sudo make install`. For CoreOS stuff I use
https://coreos.github.io/coreos-assembler/working/#using-overrides a lot which makes it
convenient to take these built binaries and launch them in qemu.
This of course gets into the broader overlap between mock/podman and Koji/Kubernetes which
is also touched on in
https://github.com/projectatomic/rpmdistro-gitoverlay/blob/master/doc/rew...
=)
It'd all be much more obvious if the RPM buildroot was just:
```
FROM
registry.fedoraproject.org/fedora-buildroot:33
RUN yum builddep foo.spec
RUN fedpkg local
```
And so if you want a pristine build locally you just use a wrapper tool which scripts
unprivileged podman. (Yes, this loses RPM caching if done naively but has other massive
advantages, such as being able to trivially spin up a shell on a remote Kube cluster that
is *exactly* the build environment, etc.)