One option smart needs to conquer the world

[Zach Garner]

> Modifying a schema upgrade on package upgrade is what is wrong (imho).

I agree in the general case. But, our package is not for public
consumption.  Smart's dowgrade feature has never caused us a problem,
but we have safe guards in place, always due testing and don't
automate the upgrades.

My point was simply that the package maintainer doesn't always write
packages to support downgrades. I suppose it is debatable whether this
is a problem the package maintainer should have to fix.

> The point is that there will *always* be exceptions that can/should not
> be downgraded. That doesn't mean that the exceptions cannot be handled
> with a "Don't downgrade this package." policy. The more interesting (and
> solvable) problem is how to specify that policy reliably, so that other,
> perfectly sensible, downgrades might be attempted.

What usually bothers me, and I suppose that this is a separate issue:
- When I do "smart upgrade", I absolutely hate it when it decides it
wants to remove certain packages. I would feel the same way if it
wanted to downgrade certain packages, though that hasn't happened.

For instance, if performing 'smart upgrade' upgrades KDE, but remove
or downgrades something equally important to me, such as Firefox, then
smart is not really doing what I want.

So, in this case, what I want is 'upgrade everything that can be, but
don't remove anything or downgrade anything'. While smart's current
behavior makes sense a lot of the times, if a user can't express the
kind of behavior  the user wants to see, then the user will not be
satisfied.

The goal, and I believe this is what you were saying, is to allow the
user to specify what the user thinks is best while also allowing smart
to have the power to do what it thinks is the best way to fullfill the
user's wishes.