Fedora Core 4

[Jeff Spaleta]

On Wed, 19 Jan 2005 15:24:25 +0100, Ralf Ertzinger
<fedora-devel at camperquake.de> wrote:
> This is entirely intentional, and I for one consider this a feature.

Package downgrades and removals are a very difficult thing to do
correctly and are dangerous as an automated concept.  With downgrades
or removals active, small packaging problems in the packages
themselves can lead to very strange behavior and unexpected behavior. 
So as an advanced user you might find the automated decision making as
to what to remove or to downgrade useful a novice user will be
confused because they might assume the downgrading is a perfectly
natural thing.

Lets take the latest wireless-tools updates-released package that
showed up as a fc3 updates-release:
wireless-tools-28-0.pre4.1.fc3.i386.rpm

wireless-tools-28-0.pre4.1
libiw.so.28
wireless-tools-27-0.pre25.3
libiw.so.27

Now... the lastest core NetworkManager and latest core kdenetwork
packages both require
libiw.so.27

Using smart to update wireless-tools from Core updates-released  
smart tells me it needs to remove kdenetwork and NetworkManager.  This
sort of thing is VERY dangerous to expose to a novice user. A novice
user can not be trusted to review the 'downgrade' and 'remove'
sections of the smart transaction and understand WHY certain packages
are in the list. How does a novice user make an informed opinion about
whether or not to let smart downgrade or remove packages?  This is a
stop and think situation... not a point and click okay situation. 
Building tools accessible to novice users that encourage them to hit a
big OK button regardless of the problem is bad.  The auto downgrading
and auto removing to meet a transaction should absolutely NOT be
turned on by default in ANY packaging tool. Sure its a very powerful
and very flexible tool for advanced users who have experience working
with packages, but for a novice user its going to be a nightmare. This
approach is not robust to packaging errors.

As a result small packaging errors that make it into the release tree
or updates tree are going to have a HUGE detrimental effect of novice
users who start trusting smart to make decisions about what should and
should not be downgraded or removed.  The whole approach to tools
contructed downgrades/removals pretty much assumes that packaging
errors will not happen.  They happen and the tools need to constructed
in a way that encourages reporting of packaging problems back to the
package maintainers instead of allowing novice users to click their
way into a situation where packaging errors result in the removal of
packages from a user's system.  I'm much more confident in up2date's
and yum's approach to a situation like this that a novice user might
face.  They keel over and die, leaving the user's system as it was. 
If there were a packaging error in a glibc update or something more
critical than wireless-tools... i would imagine that the damage smart
could do to a system by allowing users to remove a large set of
packages to make the requested transaction work would be spectacular.

-jef"is anyone running smart against rawhide... im sure there are more
than enough pathelogical packaging error cases in rawhide to chew
on"spaleta