On Fri, Feb 24, 2023 at 12:12:41PM -0800, Gordon Messmer wrote: > On 2023-02-21 12:48, Matthew Miller wrote: > > I was asked to weigh in onhttps://pagure.io/releng/issue/7215 as a > > priority. Last time we talked about this we didn't really get anywhere... > > > > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E > > > > ... and that ticket hasn't moved, because fixing it isn't trivial. > > > In that thread, Kevin noted: > > * only can make drpms at createrepo_c run time, this means you can't do > them later/on the side/keep previous ones around/etc. > * pungi doesn't have access to older rpms at the right time to generate > more and has no way to keep them accross pushes. > > If someone were interested in working on this, to fix either delta rpms, or > the vanishing security advisory problem, or both: Are there any tools, > repos, collections of scripts, etc that they would need to update in > addition to those two? Well, thats a pretty wide scope... a lot of it depends on _how_ the fix would work. I think Kevin's (the other Kevin) suggestion to enhance bodhi to inject into repodata a 'last security fix for this package' for every package in the current compose might at least help to fix that part of the missing security update problem (combined with a dnf change to read and use this data). So that would need bodhi and dnf work. It's not too clear what the best solution to drpms would be to me. If we moved drpm creation out of composes, the standlone app would still need to know what to make drpms against. Against GA content would be somewhat easy, but against previous updates... it would need to perhaps query bodhi for that? I suspect it would need to download all the rpms involved, so thats a ton of disk space, or it would need to have some other way to access them all (perhaps if we ran it in infra it could have ro access to the koji data). So that would need a new application made, dnf may need changes to look for the drpms in another repo, or perhaps we could just add a drpms repo (I don't know how dnf detects drpms off hand, but I know currently they are in the main repodata). I think it's probibly time to just let drpms go though. Bandwith vs cpu/disk space isn't as much of a good tradeoff these days. kevin
Attachment:
signature.asc
Description: PGP 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
