[Nix-dev] Openssl and fast security updates
Mathijs Kwik
mathijs at bluescreen303.nl
Fri Jun 6 13:14:45 CEST 2014
Alexander Kjeldaas <ak at formalprivacy.com> writes:
> On Fri, Jun 6, 2014 at 10:20 AM, Vladimír Čunát <vcunat at gmail.com> wrote:
>
>> On 06/06/2014 08:59 AM, Ertugrul Söylemez wrote:
>>
>>> When we use priorities generously we could avoid a lot of delay even in
>>> less critical cases.
>>>
>>
>> The main problem I see is that normally you don't want to release a
>> channel until *all* parts have rebuilt.
>>
>
> +1 Rebuilding for a server that runs, say ssh, apache, nginx, postfix and a
> few such services takes maybe 2% of the time required to build a full
> desktop distribution.
>
> I think being able to release packages used on public facing servers could
> be prioritized over, say LibreOffice, Qt, Webkit etc.
>
> If the system environment is not "polluted" by the desktop packages, it
> could be possible to upgrade the system environment before user
> environments that needs one or two orders of magnitude more time to compile.
>
> Calculating the transitive closure for all nixos modules / services run by
> systemd is one way to prioritize. A populatiry contest could be added to
> that.
That still doesn't solve the question "how to do a half build".
If there have been 5 commits since the last channel build, and you add
an important security fix, there is no way to only build that fix
without building the other stuff. A build takes a full nixpkgs checkout
and builds that. In its output, it includes a tarball with the nixpkgs
tree that was used.
The only way to _only_ get the fix is to have a separate git branch (on
top of what? release-14.04?) with just these changes and a separate
hydra target/job that only builds a few important server packages and
does not perform the expensive run-in-vm tests. But even then, I don't
know how this would magically end up on people's systems, because I
don't think you can "merge 2 channels" that both provide nixpkgs/nixos.
>
> Alexander
>
>
>>
>> We do have meta.schedulingPriority, but it's used little, and from earlier
>> discussions I think it's really hard to objectively determine which
>> packages are more important than others ;-)
>>
>> BTW, aborting jobs would need to be done very carefully, because we have
>> some jobs that run for hours, so that could lead to wasting lots of time.
>>
>>
>> Vlada
>>
>>
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
More information about the nix-dev
mailing list