On Wed, Aug 28, 2019 at 5:54 AM Pavel Raiskup <praiskup@xxxxxxxxxx> wrote: > > On Wednesday, August 28, 2019 4:06:32 AM CEST Nico Kadel-Garcia wrote: > > i will point out, from experience with subscription manager, that > > downloading RPM's from subscription-manager is unacceptably slow > > inmost build environments. You *will* want to use CentOS 8, or arrange > > a subscription to build a local mirror with "reposync", for anything > > like dynamic biulding of RHEL 8 based RPM's. But if it works, it saves > > me a bunch of work in the short term. > > I haven't experienced some unreasonably slow downloads, and my dnf/yum > caches work fine say by default with mock. > > There might be some issue, or some misconfiguration. Take a look at > mock's config option config_opts['plugin_conf']['yum_cache_opts']['dir'], > and consider not --scrub'ing the caches for every build. > > Pavel The problem dates back decades, certainly since RHEL was introduced. Testing last week with my registered RHEL 8 host, CentOS mirrors wer at least twice as fast , rather than pulling directly from Red Hat repositories, unless the company has a local Red Hat Network setup, or I activate and use a local mirror with reposync. And reposync is far less than half the speed of an "rsync" against a CentOS mirror. Some old tools of mine for just such purposes are available at thttps://github.com/nkadel/nkadel-rsync-scripts. It's not usually that big a deal when you're updating only a few packages, but when you're running "mock" you can wind up pulling from the same repos *a lot*, a local mirror really improves performance. It also reduces duplicated bandwidth from your local mirrors if you use it for Fedora, CentOS, and EPEL as well, which can save everyone resources. Unless you're worried about phase lag between your local mirror and the upstream repos, which I admit could happen with rawhide, I use it for all my "mock" builds. That includes builds of "mock" itself, in particular, whcn I've needed bleeding edge featues for older operating systems. _______________________________________________ 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
