On Fri, Sep 29, 2023 at 12:39 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Thu, Sep 28, 2023 at 01:03:08PM +0100, Richard Hughes wrote: > > On Wed, 27 Sept 2023 at 22:41, Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > I'm not sure at all that it would be possible to do at compose-time... > > > composes are taking around 3.5-4hours and thats after I have done > > > a lot to speed them up, but might be worth some benchmarking > > > to see how much slower it would be. If we are going to go that route, we > > > should see if support could be added to pungi. > > > > On server class hardware with fast disk access it's an additional 10 > > minutes or so. > > > > > Moving this from a package to in repodata would grow the repodata quite > > > a lot right? > > > > 6.9M fedora-39-icons.tar.gz > > 6.3M fedora-39.xml.gz > > So, on re-reading this thread and the upstream issues... it really seems > like the best case would be createrepo_c just adding support, but that > seems stalled/blocked due to i/o concerns? (which I can understand, but > it could be default off?) > > How does the local/rpm data interact with the repodata (if it exists)? > Or does it depend on the tool? > The data works by keying off "pkgname" and "source_pkgname" attributes that are merged into the AppStream metainfo files when building AppStream repodata. Software centers like Plasma Discover and GNOME Software will lookup these attributes for a given AppStream definition for an application and use that to request to install the package for the application. To put it more succinctly: components.component.pkgname (AppStream) maps to package.name (RPM-MD) directly. The AppStream repodata lag is tolerable because the mapping isn't to a full NEVRA. The software centers figure that out themselves on the fly. > I suppose in the short term at least if you wanted you could hand off > the generation/rpm updating to releng? (Not that releng wants more to > do, but I don't think you should carry this by yourself). > I could probably help since I know how it works, if needed/wanted. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
