I see the ongoing disagreement as to approaches in the Fedora FESCO bug, Adjust/Drop/Document batched updates policy [A], and here. I think there is some ** common ground **, fairly easy to implement, to satisfy both the: 'we need testing at once' cohort, and the: 'we are bandwidth constrained, or _churn_-adverse' group I chipped in briefly in today's FESCO meeting, but wanted to state a clean possible away forward Background: For updates, repodata is made by recursing a binary RPM tree That binary RPM tree may contain matter which has been indicated as security sensitive, and the rest not so designated Why not: 1. Continuously add to the binary RPM corpus (the present practice) 2. THEN run a new post process, where a new directory (call it 'security' for the moment) is created via 'hardlinks' (so no additional space requirements) (new) 3. If a given package is 'tagged' as security sensitive (put to one side for a moment HOW to know), add a hardlink to that new directory (new) 3a. Once the process is complete, run a 'repoclosure' test on the 'security' directory, and additional hardlinks to satisfy needed dependencies for those files, pulling from 'base' and 'updates' (similar to present practice) 4. Run a 'createrepo' on the 'security' directory, and name the output something distinctive: security-YMD comes to mind (new) 5. Once a week for say, Tuesday, run a 'repoclosure' test on the FULL directory (the present practice, but with a new output name in a moment) 5a. Raise an exception if it fails such, and bail and carp (the present practice) 6. If it passes, then run a 'createrepo' on the 'security' directory, and name the output something distinctive: patchTuesday-YMD (new) 7. Push those two sets of repodata out async, or daily, under the names (symlinks work here): security (new, so 'security' is always as fresh as possible with repoclosure) 8. - and - ONLY weekly, update the link an updated last successfully generated: patchTuesday (new) [This has the effect of fast-tracking security matter, and yet still having a pointer to the last known good complete transaction set of general updates] =========== 9. Continue to run 'normal' repoclosure, and 'createrepodata' processes. This is the full and continuous async 'updates' archive (the present practice) =========== 10. Amend the yum.conf offerings to have reference, in addition to 'updates', enabled and pointing to two new stanza's in 'updates' called: security -and- patchTuesday (new but fully backward compatible) =========== Use case narrative: If one enables both regular 'updates' and the 'security' / 'patchTuesday' config file, one gets continuous updates. If one disables regular 'updates' , one still gets updates, but only security updates get fast-tracked. If one disables the new stanza, one assumedly does not mess with 'updates' if one cares about updates (so: new, but fully backward compatible) ---------- Sidenote: Above, I put to one side how to ascertain that something is: 'tagged' as security sensitive I would suggest that if an update is asserted to be security sensitive, just add to the top Changelog entry: a tag with a "[CVE YYYY-NNNN]" reference, or once any embargo has passed, a tag with a "[Security]" reference and a pointer to the long form description of the issue in play It is trivial to extract the --changelog first stanza from a package, and so scan it and branch accordingly, if such are found, in building the 'security' hardlinked working copy -- Russ herrold A. https://pagure.io/fesco/issue/1820 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
