Am 08.08.2012 12:08, schrieb Karanbir Singh: > 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 ? In fact most people I know are only interested in wether the patches/updates they're missing fix a security issue or not. More information is interesting, but not crucial. The question usually is: should I install these right now or can I wait another day? In fact some of my customers only install bugfixes in one batch with security fixes. > 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. Point taken. But then we can just take another approach placing the updateinfo. > > Lets only consider doing that if there is realistically no way to fix > the problem without making that big a change to mirroring requirements. > [...] I'd strongly discourage the use of vault.centos.org for stuff like that and there's a rather simple way to get around changing anything on the mirrors. > 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 ). We could have some kind of repository containing all the updateinfo snippets (Wiki, Database, git repo, you-name-it). When generating the repository metadata you just pull all snippets that mention any of the rpms in your repo and assemble your updateinfo.xml. While doing that you'll immediately find all rpms that lack updateinfo. > 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. I know how it works for RH. Problem is: we don't have anything like that. First time you ship something broken that needs to be fixed the CentOS numbering scheme will break. Also there's currently no way to name Errata for the centosplus and/or extras repositories. 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