--
Gwyn Ciesla
she/her/hers
------------------------------------------------
in your fear, seek only peace
in your fear, seek only love
-d. bowie
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, January 27, 2021 11:26 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
Dne 27. 01. 21 v 17:57 Gwyn Ciesla via devel napsal(a):
> --
> Gwyn Ciesla
> she/her/hers
> ------------------------------------------------
> in your fear, seek only peace
> in your fear, seek only love
> -d. bowie
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Wednesday, January 27, 2021 10:50 AM, Vít Ondruch <vondruch(a)redhat.com>
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.
>
> Ok, let's say I have to update a library, let's say
LibRaw, and the soname changes.
>
> I fire up a rawhide VM
This is the first difference, with Mock, you don't need to fire
VM.
> , and clone the LibRaw repo, update the spec
Second difference is that you are cloning locally.
> , build
At this place, you call `fedpkg srpm` followed by `mock LibRaw.srpm`
> , and install it
`mock -i
/var/lib/cache/mock/fedora-rawhide-x86_64/results/LibRaw.rpm`
> . Then I clone the dependant repos, update their specs, and
build them.
These are all more cumbersome to type quickly. fedpkg mockbuild solves that but I
doesn't support the options you use. fedpkg local does what I and apparently many
others need.
You clone them locally and you call the `mock dependant.srpm
--no-clean`. Please note that the --no-clean is essential here, because otherwise the BR
would be cleaned up as well as the results directory previously used for installation. But
of course you can save the build results somewhere.
> Failures are immediately apparent, and I can quickly work on
patches or obtain logs of failures for sending upstream. I can easily get into the source
tree to examine files
Sure you can with mock, you have everything at
`/var/lib/cache/mock/fedora-rawhide-x86_64/root`
> , quickly test tweaks to build commands, etc. Once it all
builds, I do a mock chain build, then an srpm koji scratch build, and if all is well, I
commit, push, and chain-build in koji.
No difference here.
> I always use mock for final smoketesting and rooting out missed
BuildRequires, but being forced to use mock for the whole process would greatly lengthen
the process.
This is where I disagree. You would save you troubles using VM. Mock
is more lightweight providing you everything you need.
BTW, I should note here that I am not user of `fedpkb mockbuild`. I
believe that using mock directly is not harder. The same way as I am using `git commit`
where others could prefer `fedpkg commit`.
Vít