What about smartpm?

[Jeff Spaleta]

On 11/29/05, Tim Fenn <fenn at stanford.edu> 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