-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJULGVMAAoJEBbHyC76Ca13hRQP/iQg0GUt1mzpO8WfJpRxCukd hOmPGqlP4Jw/DSS6ZNRAdsM8RMbLu0ekEnRuJfXl6a7rWfWys1HYZXg1yidoqY7j /X4E4MAcQ9JroNgJceOh3RGWbmR2xwAY+x/TW524RXPs74DXWq8KdDjcHaAuU66z GJ0/GpvqXjPIAcdwD2fmSJV/3J4Qq7TuDltjJdKw04QstkWpVfaTcXCSkps/5Eet nQkO6okdaAFiUQBRyGTNYgD9f4+LLeNU0Of3xPFbzRogpHijOmD+WOWCQ4hZIsl3 PUnSTWZVqHW67osTYH+jR7AcQ2fVqyacqWAJZpRLsm8PYTdsPeu/GAzQxHHef486 LcGtAeEiyEYcJKhLOSqfnpntJ1bdpFxLqdaU+TYXib5CydgIYh5msy1KbN53RUL/ OrN75hqFSUuqeO2qT7fsjjGTc6YD7sXBRv0zQSqjc11mJ83jkl9+PYOONKqMMyW/ VbWHwvxfMmF6MYyxJrAblLZq37hDyMShNxSVL2eMsOw3erK7Q5uz0f8CdP+mMmdK LCvwgr0wxdSChwrtngR9tgysU/zT0/GMRFPGUJq/I+d9obahJ+5BSAbUb02ZLWO4 F+q1Ep1Rgt0O8WUrz7hcP9md3Jha/XG/kxP9yjGjxvpzJ2QM5tiEItr+MYRxK8z/ 03rnxFJC2jBmRhvHX/0p =86I9 -----END PGP SIGNATURE-----