On Wed, 19 Jan 2005 15:24:25 +0100, Ralf Ertzinger <fedora-devel@xxxxxxxxxxxxxx> 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
