Good Morning! I hope you read my contribution to the thread on -devel-list. But if you don't i'd like to point out the specific example of where i think smart's behavior is wrong and to it to frame an argument as to what i think smart could be doing instead of using per-package and per-repo priorities. The example i want to show you is the newest wireless-tools in updates-released: wireless-tools-28-0.pre4.1.fc3.i386.rpm which provides libiw.so.28 the latest NetworkManager and kdenetwork in Core require libiw.so.27 as a result if i try to use smart to update to the latest wireless-tools package in updates-released, smart wants to remove NetworkManager and kdenetwork from my fc3 system. I feel this is incorrect behavior, smart should understand this situation as a reportable packaging error instead of offering to remove those 2 packages to make the transaction work. This is clearly a case of a package bug leading to unrequired package removals.. and I am concerned that a novice user with little experience with rpms won't have enough information to cancel the operation and similar operations if there is a packaging error. My solution to this sort of problem in smart is to move a way from fully exposing per-package and per-repository priorities and to move toward codifying the relationship between channels in a way that codefies how channel interaction policy is being handled by the channel maintainers themselves. The key idea is for channel maintainers to define for themselves how they fit into a multiple channel frame work, and smart can use that information to flag error situations that should not be happening according to channel policy. Let me construct for you a simple hypothetical setup of channels based on Core 3 and show how it could help prevent the wireless-tools packaging problem. Lets start with just the Core channels: Core3os: The channel for fc3 os, this channel explicit states as a matter of policy that it is self-consistent and that it requires no dependances from anwhere else. And conflicts between packages in Core should be considered a reportable bug Core3updates: The channel for core 3 updates-released This channel states as a matter of policy that it is self-consistent and that it updates Core3os, any conflict when packages in Core3os and Core3updates are used together should be considered a reportable bug. Core3testing: The channel for core 3 updates-testing Core3os:
