-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2014 02:41 PM, Kevin Stange wrote:
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.
That's great for you. It misses the larger picture of the distro as a whole and how many people who are not you choose to use the distribution.
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.
There's no maybe to it. This *does* create a false sense of security. Hang out on the forums for a while, or come sit in #centos on freenode for a while to see how people are installing and using. How many times have people posted to the list that they MUST (for varying definitions of the word) pin to a particular release for a vendor requirement, but they still want updates. Your ideal use case breaks for a wide array of the users we deal with daily.
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.
It's equally unreasonable to arbitrarily rule out a large chunk of the user base because it doesn't fall in line with your uses.
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.
Then you're choosing to largely ignore the functionality the plugin provides.
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.
While I don't disagree, I have no intention of implementing a half-baked, broken solution that allows users to *think* they're secure when they're very much not. For individual use cases, this is easy to solve. to do it properly for the distro itself is quite another matter.
- -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77