bug#33370: guix publish: at least one user will have to build a given substitute

[ludo@gnu.org (Ludovic Courtès)]

Hi,

Clément Lassieur <clement@lassieur.org> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello,
>>
>> Clément Lassieur <clement@lassieur.org> skribis:
>>
>>> I've noticed that narinfo baking is triggered by user requests when the
>>> '--cache' option of 'guix publish' is used.  It means that the first
>>> user who will want it will get the 404 response and will have to build
>>> it manually.  (See guix/scripts/publish.scm, make-request-handler.)
>>
>> Note that the first request (404) returns with an expiry of 5mn instead
>> of the default (much longer) expiry for “normal” 404s.
>>
>> We discussed this behavior at length back then and that seemed to me
>> like a reasonable behavior for a service with many users: the first one
>> gets 404 (or has to wait for 5 more minutes), but when there are enough
>> users, it doesn’t matter much.
>
> But at least one user will complain, and if it's a small laptop building
> Icecat...

The way we’re doing things, there’s necessarily a delay (the build time
plus some additional latency) between the moment and commit is pushed
and the moment the corresponding package is built.  Baking only adds a
very small latency.

>> This would be useful in reducing latency; the downside is that we’d bake
>> lots of things, even possibly things that nobody ever needs.
>>
>> Thoughts?
>
> What about getting the first user to block until the baking is done?

That’s generally not possible because HTTP is supposedly synchronous.
Also, ‘guix publish’ has a bunch of worker threads that pick baking
tasks from a queue.  When the queue is empty and you asking for a
substitute of sed, it will take seconds to bake it; but when the queue
is already large and you’re asking for LibreOffice, it could take a few
minutes.

For the intended use case, which is a build farm with many users,
optimizing for the first user makes little sense IMO.

Thanks,
Ludo’.