Smartrpm was (Re: Fedora Core 4)

[Jeff Spaleta]

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: