Re: Proposal to deprecated `fedpkg local`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxxxxxx> 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.


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


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux