Am 01.08.2012 18:49, schrieb Karanbir Singh: > hi Guys, > > with a bit of time opening up, I've gone back to looking at the > yum-security issue and how we can address it ( i.e: atleast get the > basics working ). Thank you so much for starting this effort! > I plan on doing the work in multiple stages as : > > 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. > 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. So we would have: /6/updates/... /6/extras/... /6/centosplus/... to contain all update-rpms for all point-releases and the rpms released at point releases. Additionally you would place symlinks for isos and os to point to the last point-release directory And the point-release directories would boil down to: /6.0/isos/... /6.0/os/... to contain the installation media and mayve a set of symlinks pointing to the repos in /6/ If splitting like that it is quite simple: You add updateinfo.xml to all repositories below /6/ and make the listing of all contained rpms in updateinfo.xml a requirement. For the point releases you don't want or need any updateinfo.xml as anaconda doesn't support updateinfo.xml and the repository will only be used for installs and not for updates. > One way to work around this would be to have yum consider all interim > package metadata between installed.rpm and latest-in-repo.rpm ( which > would then mean that we would need the yum-security metadata to contain > all info for everything ever released ; isnt a problem as such ). 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. In fact you can probably put the complete updateinfo into every base and updates repository without messing anything up. Without messing around with the overall mirror- and repository-layout this is probably the easiest way to handle it. If we kept the updateinfo in a database or something else that searchable and machine readable in an efficient manner one could also generate an accurate updateinfo.xml for every repository. This would also make testing much easier: if you want to test stuff, you can simply generate your own updateinfo.xml for your own local mirror by querying the database using a custom query. > I feel its important that if we are going to provide a mechanism that > people will then in turn rely on to get patch requirements for their > machines, we need to make sure we have 100% coverage. 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. Upstream has a release-number on their errata and we should probably also introduce one. Additionally we will want another centos-own numbering scheme for updates that do not duplicate upstream errata (i.e. stuff that goes to extras or centosplus). Scenario 1: Sometimes you will have to change errata that were already released. Say you have CESA-2012:123 that fixes a flaw in a a package contained in CentOS 5, CentOS 6 and the upcoming CentOS 7. As CentOS 7 is not yet done, we push out the errata for CentOS 5 and 6. This is "CESA-2012:123-1". Once CentOS 7 is done, the update would be release for CentOS 7, too. This requires a change to the already release errata, so its version should be increased to "CESA-2012:123-2". Scenario 2: You build the packages for CEEA-2012:456 and push them to the mirrors. By doing that CEEA-2012:456-1 is released. However, you realize that you really broke stuff and you have to push fixed packages immediately. As you changed a released errata, you have to change its version making it CEEA-2012:456-2 Regards, Andreas -- Solvention Ltd. & Co. KG St.-Sebastianus-Str. 5 51147 Köln Tel: +49 2203 989967-0 Fax: +49 2203 989967-9 http://www.solvention.de mailto:info at solvention.de