On 12/5/05, Nicolas Mailhot <nicolas.mailhot@xxxxxxxxxxx> wrote: > Jeff Spaleta wrote: > MS reasons for holding back some stuff are not applicable to Fedora. > Fedora userbase is not segmented between legitimate users (which can get > full updates by going through a portal) and freeloaders (which MS would > dearly love to leave in the dust, but can not for PR reasons). I make no claim as to why MS does anything... you brought up MS not me. But I thank you for the lesson in conspiracy theory. > If you really worry about missed critical updates make partial updating > a repo parameter, separate critical updates from other stuff and set > partial=false for the critical update channel. Isn't missed security updates... the underlying concern for everyone in this discussion? This per-repo trick would only work if security updates are actually housed in a seperate repo than non-security updates. That doesn't really work at all with the current repo structure. > I contend you'll get the same results by simply counting how many times > a package fails updating and warning when it gets over some threshold, > but if having one repo where yum balks at the first problem makes you > happier, you can do it this way too. No, not really. I'm not really excited about tools taking a week to notify users of update failures. This whole discussion has been prompted about getting updates asap. Waiting a week to notify a user about a broken critically important security fix.. seeks counter to everyone's desire. It is my contention that reliable auto-updates must make a distinction about security/non-security failures and clearly notify the user asap about security update failures so the user can assess what actions to take. I'm not in favor of encouraging any automated update installation that does not attempt to account for the known security rating when informing the user as to update failures. What I want is the best practise for security updates that can be implemented for the project. If non-interactive partial updates are to be encouraged I want there to be a clear way for the client tools to tell users if any security updates failed. I don't want the security update failure buried indistinquishably in a log of 300 other non-security failures. By my count there have been 354 different update annoucement emails for FC 4 updates since July 7th (when the new update annoucement stuff went live). 69 of those have been tagged as security... 20% or so. How many reported problems with updating in that time have been from security updates as compared to problems with non-security updates? If someone were to do an everything install of Core on any given day and partial autoupdating was encouraged. Which security updates would be held back? Which non-security updates would be held back? Today at the very least, the kernel would be held back due to the GFS packages. I feel that users who rely on auto-updating for security would get a false sense of security by auto-updating without there being a notifcation mechanism to clearly notify the user of unapplied security updates asap. I believe that a false sense of security can be more dangerous than actual insecurity because a false sense of security will embolden some people to take risks they otherwise would not if they knew their were vulnerable. Feel free to disagree. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
