-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/01/2014 03:34 PM, Jim Perrin wrote:
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.
I am trying to do something with spacewalk that doesn't have any of these implications. Regardless, the yum plugin has more potential to be useful for the vast majority of CentOS users than harmful, in my opinion.
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.
This is not a valid use case of the software in the first place, as Johnny has indicated. CentOS isn't testing the updates in cases of pinning to a specific release and updating selectively. If you don't test or plan for that to work, then this case is also not really important either.
Johnny already said there's no guarantee the security updates even provide security in that case, so maybe this whole talk of the plugin is irrelevant for this entire pinning to specific release use case.
If we ignore that case, it's still useful in the supported use case of updating packages within the same release version, in the plugin and in all other systems that make use of the data.
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.
I am not ruling anyone out, this feature simply doesn't apply to their circumstances. Yet, it still benefits other people to have it.
They are already using the software in a way that is not supported or recommended, by several statements already made in this thread.
My interest is in running the software in the supported and recommended way, with all updates installed, but I am still interested in knowing what I'm updating and why. That's a huge part of having this data exposed.
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.
Yes. I am not here because of that plugin. I am here because other things use this data beside the thing that people shouldn't be doing anyway.
No one brought up the plugin in the previous thread. I just got into this one because it is another thing that can use this data, and someone asked what it would take to make that plugin work.
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.
Somehow this information is apparently useful, supported and functional in Fedora and SL. What are they doing to make sure it's not half-baked and broken? Anyone from SL or Fedora here that could answer that question?
I suspect they're just providing the information and letting users make their own decisions on it. Fedora doesn't even keep multiple updates on the mirrors during a release cycle. They only leave the latest version of each package in their updates/ directory.
I'm not trying to make the argument that because one distro does something, it must be good. However it seems to be doing what it's supposed to in these cases. I use Fedora 20 and having the update manager remind me that I should update because one of the packages has a security impact is better than never having that data at all.
- -- Kevin Stange Chief Technology Officer Steadfast | http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688