Re: Proposal: drop delta rpms (for real this time)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux