-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2014 01:10 PM, Johnny Hughes wrote:
On 10/01/2014 12:58 PM, Johnny Hughes wrote:
On 10/01/2014 12:11 PM, Kevin Stange wrote:
<snip>
CentOS is the community .. why don't you figure it out and maintain it as a SIG?
If the idea of a SIG permits managing changes to the core distribution's repodata to add this metadata, then it can be a SIG, but the SIG will need direct access to the mirror network to implement the required changes.
But I don't think this should be a SIG. It should be part of the core product and it should be done in real time when the repos are updated and the update bulletins are created.
How would we handle this scenario:
I user has 6.3 installed, they have never updated. We are on 6.5.
Package abc-1.2.3 is installed on their machine, it is on the 6.3 iso that they installed from.
Package abc-1.2.4 is a security update and in 6.4.
Package abc-1.2.5 is a bugfix only update in 6.5.
The guy says .. yum update security only.
The info in the xml file says abc-1.2.4 is the right package, but it is not installable from 6.5 .. what happens?
I'll be honest: I don't care about this scenario at all. My spacewalk server would take care of this just by virtue of CentOS having the data ever available for these packages and constantly keeping itself current.
However, in this case, what would happen would be that 1.2.4 would not exist in the updateinfo.xml at all, so the user would receive no update for that particular package on the basis of security, but would still receive updates for all the other security packages marked in updateinfo.xml. Maybe that creates a false sense of security, but why have they not been installing these updates from 6.3 to 6.5 in the meantime? Perhaps they don't follow the centos-announce list and have missed out on all CESAs in the past few years. The updateinfo.xml enables continuously keeping tabs on security issues as they come up, and it's perfectly effective when people are doing reasonable things already with regard to selectively installing security updates are caught up to current (6.5) distribution.
Honestly, if someone is using 6.3 and has not been keeping up with security or upgraded to 6.4 or 6.5 by now, it's really already such a bad state that I don't think it matters if this should work. I don't think it is appropriate to dismiss the entire idea on the basis that some people doing unreasonable things won't find it useful.
My interest in this feature has nothing to do with selective updating. That is not my objective and I don't care if it works. I am interested in metadata that provides information, so people have easier and pervasive access to that data when they perform their regular updates to the supported versions of the system.
Having the only source of information be the centos-announce mailing list is the problem I want solved. There should be a feed that makes use of the already existing tools that ship with the system, and that is what updateinfo.xml is for.
- -- Kevin Stange Chief Technology Officer Steadfast | http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688