On Thu, Jan 28, 2021 at 12:55 PM Vít Ondruch <vondruch@redhat.com> wrote:

I have started the thread reflecting on experience of fresh packager
coming to Fedora. First issue was that `fedpkg local` pollutes the work
directory. There is also second issue, that `fedpkg local` is polluting
the whole system with build dependencies (and this is my concern). I
don't think that anybody should have polluted work directory and their
system by packagers work. If experienced packages are fine with that, so
be it. But I am concerned, that these practices are possibly suggested
to fresh coming people.

I've largely been lurking, but my $0.02 worth...

I used to use rpmbuild directly all the time, and while I only maintained a few packages having those build deps installed wasn't much of a big deal. However now that I maintain many times more packages, I can say that I never use rpmbuild -ba or fedpkg local, instead I just deal with the little bit of extra time it takes to setup the chroot. That being said I have a Ryzen 5 3600 w/ 32GB of memory and a Samsung 960 EVO m.2 drive so it's not THAT bad for me. 

If there is a build failure I attempt a fix and use --no-clean which speeds up the following builds quite a bit. So a couple of ways I deal with build failures:

1/ Patches don't apply cleanly

I use quilt which works OK but it does not play nice with spec files 100%. It essentially stops at the first patch failure so once I fix that I have to delete the directory and run quilt setup again. This is less than ideal. I also wish it didn't erase the non-patch parts which are often used to put contextual information or github patch info.

2/ Ambiguous build failure error message or segfault. 

Here I use the shell option to go into to chroot. It has some quirks as well. It drops you into the root so you have to do the whole cd builddir/build/BUILD/... or something like that (I'm at $DAYJOB right now). Could it not take you directly to the build dir?

Also useful tools like vim or less need to be explicitly installed and often don't work exactly the same inside the chroot as they do outside. BUT it does allow you to interrogate/troubleshoot binaries and test, etc.


I have already withdrew the original proposal, but that does not mean I
am less concerned.

I don't think it's a waste. I agree that we should encourage use of mock/fedpkg mockbuild in the documentation but we could also try to remove/reduce the reasons people use fedpkg local.

Thanks,
Richard