On Wed, 19 Jan 2005 14:38:22 -0200, Gustavo Niemeyer <niemeyer@xxxxxxxxxxxxx> wrote: > That's exactly the idea. We're all in the same boat, looking at > the same issues from different angles. Smart has algorithms to > choose a better possibility given the available options. Jeff > seems to be looking for a debug tool to detect broken > distributions. Actually... im not looking for a debugging tool. I'm looking to find a balance between ultimate flexibility and robustness in the face of packaging errors in a way that protects novice users from errors in situations where errors are obvious based on our human understanding of how a channel is suppose to operate. I think we can all pretty much agree that if a Core updates-released package requires the removal of a Core package without an explicit obsolete tag being set, there is a problem there and it should be identified as an error. Novice users will click their way through pretty much any set of dialogs you give them, without blinking. If you present this case to a novice user they will simply do what smart suggests. And in the wireless-tools case smart's suggestion is sub-optimal to doing nothing. There is absolutely no good reason to provide a simple UI that encourages average users to commit package update transactions that are trying to work around internal package conflicts inside Core + Updates. These situations should NEVER happen, and we all know that. If the end-user tools lets them happen with a simple click of the mouse, thats a huge usability problem and its going to lead directly to broken systems. Flexibility needs to be tempered with robustness to errors. Point and click tools aimed at the average user, absolutely need to be designed to prevent novice users from taking action based on erronous packaging information as much as possible. A lot of what smart does when trying to be 'smart' breaks rpm mechanisms for constraining the dependancy space inside a self-consistent channel. smart's logic tries very hard to find a 'best fit' solution to a large multi-repo space but at the cost of removing consistency checks meant to be used when a channel or a group of channels is designed to be self-consistent. Its one thing to be clever and know that when you want to install a package from atrpms you should remove a conflicting core package because atrpms and core are not designed to be self-consistent as a pair. Its quite another to be so clever that you forget that Core itself is self-consistent and that Core+Updates-released is suppose to be self-consistent. What i want is to give smart's flexibility scope based on the understanding of how a channel is suppose to work and how a channel is suppose to work with other channels. installing something from livna, as a matter of channel policy, shouldn't require the removal of a core package.. we all know this.. its a stated policy for the livna channel. The update of a updates-released package shouldn't require the removal of a core package without an explicit obsolete being set... we know this.. this is a stated policy of how updates are suppose to work. These 'policy' definitions for the livna and the updates-released channel should be respected by packaging tools and should be used in the calculation of 'best' transaction to avoid offering any transaction that we know should never be presented to a user because it HAS to be the result of a packaging error according to established channel policy for the channels invovled in the transaction. We must build tools that protect users from errenous packaging. Epochs exist for a reasons... smart breaks the epoch functionality on purpose to perform superflexible dowgrades... regardless of which channels are being used in the transaction. This superflexible epoch ignore shouldn't be used in transactions in a self-consistent set of channels. There is no good reason to engage in this level of flexibility if you only have Core and Core Updates as active channels in the transaction set... this will lead to unexpected breakage for novice users when package errors are introduced. Obsolete tags exist for a reason... smart breaks the obsolete functionality to perform superflexible package removals across overlapping channels. There is no good reason to remove Core packages when updating a Core Update if there isn't an explicit obsolete being set. This will lead to unexpected breakage for novice users when package errors are introduced. Its a matter of finding a way to encode each channel's understood policy so that smart only offers transactions we are sure are not the result of packaging errors. The wireless-tools example is a concrete example of an offered transaction that should be prevented based on the expectation of how the updates channel is suppose to work. The only reason smart offers the transaction it does... is because there is a packaging error. Garbage in- garbage out. This situation can be refined if understood channel policy constraints are used in smart's transaction calculation. Since we know Core updates should never need to remove a Core package without an obsoletes tag, smart should avoid offering any transaction that would require that. -jef
