[Buildroot] [PATCH=2020.02.x] package/redis: bump version to 5.0.9

[Thomas Petazzoni]

Hello,

On Mon, 29 Jun 2020 17:30:49 +0200
Titouan Christophe <titouan.christophe at railnova.eu> wrote:

> Generally speaking, pkg-stats does 2 different things:
> 
> 1. Collect information about the packages in the Buildroot tree 
> (version, number of patches, developers, ...). This information changes 
> with the Buildroot tree, and is therefore *STATIC* for a given version 
> of Buildroot.
> 
> 2. Matching the packages against CVEs and release-monitoring. This 
> information is *DYNAMIC* and can change anytime, because it is based on 
> services that are independent of Buildroot.

True.

> Therefore, we could split this process in two distinct parts:
> 
> First, collecting the packages information into a static JSON file (or 
> any other format you like), like some kind of "manifest". This could be 
> done once for each release of Buildroot, and in a nightly job for 
> master/next/<whatever dev branch>. Maybe we could even reuse (some parts 
> of) `make show-info` for that purpose ?
> 
> Secondly, check the CVEs and new pkg versions using as input the static 
> "manifest" file obtained above. This could be done in a nightly job for 
> all the active releases of Buildroot (latest LTS and "regular" release, 
> master, next, ...).

I hadn't thought of it this way.

> This would provide the following advantages:
> 
> - No need to have a full BR tree to generate the CVEs/outdated packages 
> list (only the "manifest") => easier to run for multiple BR versions and 
> to run in parallel

Is this really a relevant advantage ?

> - The "manifest" can be stripped down to the list of packages used in a 
> particular BR config, such as to customize the pkg-stat output to what 
> is relevant to the user (what your colleague Gregory is working on if I 
> understand correctly ?)

The tooling Grégory is doing is using the "make show-info" output as an
input to know what packages are enabled (and their version, ignored
CVEs, etc.) and does a match against the NVD database. The code doing
the match against the NVD database is factored out from the pkg-stats
script so that it is shared.

> - This makes it easier to plug a frontend (like the one Heiko was 
> working on) describing the packages available in a certain BR release, 
> and optionally the daily regenerated stats of these packages.

Well, the frontend from Heiko also needs the dynamic information
(release-monitoring, NVD) and so from that perspective splitting out
the "static" info from the "dynamic" info.

All in all, I don't know. Perhaps it could be useful, but the few
arguments to my eyes don't really bring any new really useful great
feature.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com