hi Andreas,
On 08/02/2012 12:54 PM, Andreas Rogge wrote:
step1: get a basic set of metadata online so that people can detect if an update is tag'd security, bugfix or enhancement
That's probably what 90% of people will be happy with.
interesting. are you saying that most people are not interested in tracking specific CVE's etc ?
What we have right now only provides for the<version>.<release> rpmset and updates but only in relation to that specific tree (eg. /6.3/ is what /6/ maps to at the moment ). Yum-security metadata in this repo would then only be relevant to the rpms contained in /6.3/, whatever repo they might be in - however, someone running 6.0 or 6.1. when checking for updates is likely to miss interim updates that were security tag'd at some release level or the other.
Probably. But that's an issue with the mirror- and repository-layout. The solution to this is having one continous updates-repository per distro-version instead of one per point-release.
problem with the new layout is that every mirror will now need ~ 1TiB of storage ( compared with the ~ 80 GB needed now ); with hardlinking aggressively, we could bring that down to about 600GB or so, but its still way too much.
Lets only consider doing that if there is realistically no way to fix the problem without making that big a change to mirroring requirements. The other option we have is that yum-security would need to rely on centos-release-extras, which in turn can ship a CentOS-Vault repo, with the relevant metadata included from vault. The only change that would need is that vault.centos.org needs to not only contain older packages, but also ones from the present tree.
There is no way to really tell, but I feel uptake for yum-security is going to be a small number of people across all CentOS users - and we might be able to satisfy demand with a reasonable performance level by adding a few more machines to Vault.centos.org rather than changing mirror.centos.org and all the external mirrors.
I'd just go down that road. I wouldn't even make a difference for architectures and you can argue wether it is worth the effort to differenciate between major releases.
right, thats the point - to make yum-security worthwhile, it needs to not consider point releases, the whole distro ver needs to be considered in one stack.
Coverage is important, but it is rather simple to test: just make sure every package in you repo is mentioned in updateinfo.xml. Maybe throw in a blacklist with the packages from the x.0-release. What is much harder to achieve is reliability and consistency of the information provided.
the plan is to have the generation code hard wired into the script which pushes rpms to the updates/ repo. that should mostly solve the problem going forward; for retrospective updates and for rpms released into the base os at point release time, i think it will haveto be a manual effort for now. Maybe we can try and get some level of smartness sorted for 6.4 and beyond, but for now it will need to be a manual effort ( which I am trying to reduce as much as possible ).
Upstream has a release-number on their errata and we should probably also introduce one.
as far as I can tell that -<release> for errata is to handle internal RH oops' rather than something that is exported publicly. Once something is marked as public, they dont increment the release number, which is good. The only exception I have seen to that is when they update releaes to change grammar or text within a release announcement. A real fix or change to the packages would have to be via a new errata notice.