On Fri, 12 Jul 2019 at 08:05, Leon Fauster via CentOS-devel < centos-devel at centos.org> wrote: > Am 12.07.2019 um 02:54 schrieb Nico Kadel-Garcia <nkadel at gmail.com>: > > > > > On top of that, I build a local copy of mock, using my tools at > > https://github.com/nkadel/nkadel-rhel-8-mockrepo . EPEL 8 is welcome > > to my tools to build mock from that repo.. Building RHEL 8 or EPEL 8 > > packages requires setting up the relevant "epel-8-x86_64.cfg" to use > > the "best=0" setting, to avoid confusion about the "module" RPMs. > > > Reading this, I wonder if its possible to build the meta information for > module > packages out of a rpm list (without additional knowledge)? Similar to > createrepo > that works just pointing to a directory. Scenario: pinning a version or > incorporating > upstream packages in a local repository. Just curious because that module > thing > completely passed me by since I don't use fedora. So, EL8 put the wall in > front of me :-) > > There are multiple definitions, filters, controls and other data which are in the modular data file which an rpm list does not have.. much of that data is used in some form. Here is the section for squid from today's in modules.yaml.gz file --- document: modulemd version: 2 data: name: squid stream: 4 version: 820181213143653 context: 9edba152 arch: x86_64 summary: Squid - Optimising Web Delivery description: >- an initial version of the squid caching proxy module license: module: - MIT content: - BSD - GPLv2+ and (LGPLv2+ and MIT and BSD and Public Domain) xmd: mbs: mse: TRUE scmurl: git:// pkgs.devel.redhat.com/modules/squid?#21e20d36bd79e5a938598ac24dfb9f74b56028ad commit: 21e20d36bd79e5a938598ac24dfb9f74b56028ad buildrequires: platform: stream_collision_modules: stream: el8 ref: virtual filtered_rpms: [] ursine_rpms: koji_tag: module-rhel-8.0.0-build version: 2 context: 00000000 rpms: squid: ref: c8510e2ed3af9860df1a961795e47e6070621a18 libecap: ref: 1d5fed47e0ff19fa962034645d42bf2e5a2564dc dependencies: - buildrequires: platform: [el8] requires: platform: [el8] references: documentation: http://www.squid-cache.org/Doc/ tracker: https://bugs.squid-cache.org/index.cgi profiles: common: rpms: - squid api: rpms: - squid components: rpms: libecap: rationale: library needed by Squid repository: git://pkgs.devel.redhat.com/rpms/libecap cache: http://pkgs.devel.redhat.com/repo/pkgs/libecap ref: stream-1.0 buildorder: 1 arches: [aarch64, i686, ppc64le, s390x, x86_64] squid: rationale: squid caching proxy repository: git://pkgs.devel.redhat.com/rpms/squid cache: http://pkgs.devel.redhat.com/repo/pkgs/squid ref: stream-4 buildorder: 2 arches: [aarch64, i686, ppc64le, s390x, x86_64] artifacts: rpms: - libecap-0:1.0.1-1.module+el8+2479+dae5d0d3.x86_64 - libecap-devel-0:1.0.1-1.module+el8+2479+dae5d0d3.x86_64 - squid-7:4.4-4.module+el8+2479+dae5d0d3.x86_64 ... --- document: modulemd-defaults version: 1 data: module: squid stream: 4 profiles: 4: [common] ... There may be some other data spread through the file which would be needed for it to use this. This is one of the least complicated ones as it does not have anything which is supposed to tell pungi to filter out packages in the final compose or dependency chains in what it conflicts or requires. Those are very long in text.. so I didn't want to spam email more than I am already with the above. > -- > LF > > > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190712/d5f40615/attachment-0008.html>