On Wed, Jan 10, 2018 at 2:23 PM, Andrew Lutomirski <luto(a)mit.edu> wrote:
> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi <kevin(a)scrye.com>
wrote:
>
>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
>> Kevin Fenzi wrote:
>>> Well, if this firefox update was urgent, shouldn't it have been marked
>>> urgent?
>>
>> Urgency is always in the eye of the beholder. I as a user consider all
>> security updates "urgent", and in addition, I want ALL updates as soon
as
>> they passed testing no matter whether they actually are urgent.
>
> You also don't want updates-testing to even exist right?
>
>>
>>>> I really don't understand why we do this "batched" thing to
begin with.
>>>
>>> To reduce the constant flow of updates that are very minor or affect
>>> very few mixed in with the major updates that affect lots of people and
>>> are urgent.
>>
>> But the users were already able to opt to update only weekly. So why force a
>> fixed schedule on them?
>
> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo.
Could Fedora, perhaps, come up with a way to make incremental metadata
updates fast? This shouldn't be particularly hard -- a tool like
casync or even svn should work pretty well. Or it could be a simple
ad-hoc thing. Have the mirrors serve up both the whole metadata blob
and a list of metadata changes. The client could grab the list of
changes from last time, compute a bitwise-identical blob, and verify
the signature on that, deltarpm style. (But on the decompressed data,
of course -- no need to repeat the mistakes of the past.)
It seems that all this batched stuff is a rather weak hack to work
around the extreme inefficiency of Fedora's metadata distribution
model.
This was actually prototyped two years ago with zsync:
https://github.com/rh-lab-q/deltametadata-prototype
It worked, but it was slow since it wasn't implemented in librepo and
of course we never got it implemented in the infrastructure.
Details:
https://github.com/rh-lab-q/deltametadata-prototype/wiki/Deltametadata-of...
The Plan of 2017 that never got done:
https://github.com/rh-lab-q/deltametadata-prototype/wiki/Plan-2017
--
真実はいつも一つ!/ Always, there's only one truth!