On 11/29/05, Tim Fenn <fenn@xxxxxxxxxxxx> wrote: > Yeah, and this is still unsafe, because upgrading is inherently, > implicitly unsafe. > > 1. you can upgrade into a vulnerability > 2. upgrading often breaks, since newer versions can do things in %pre > that make upgrading to a workable state impossible. > > And have it be equally valid? ;) Are you here to argue semantics or are you here to have a constructive conversation? The issue is about "known" vulnerabilities and "expected" problems based on how scriplets are designed to work. Vulnerabilities get fixed with upgrades as they are discovered and developers respond. Its pretty clear to anyone willing to be rational, that software updates are inspired to deal with "known" vulnerabilities. Tools that takes the thought out of downgrading into a known insecurity from a more security state does those users a disservice. This of course is not the strongest argument that can be made against downgrading, since notification about security issues could be incorporated either from the changelog difference or from seperate notification text to inform the users of the risk. The stronger argument against this behavior is about how rpm packages are actually designed and tested. How much testing does anyone do with regard to downgrades? Is there any packager out there that creates upgrades to fix issues regarding downgrading? I'll go out on a limb and suggest that the number of maintainers who do spend any time on making sure downgrades work smoothly is vanishingly small. We know this situation gets absolutely no testing, and gets absolutely no maintenance and as a result tools should not be automating the process when the results are ill-defined. -jef -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
