Smartrpm was (Re: Fedora Core 4)
Jeff Spaleta
jspaleta at gmail.com
Wed Jan 19 15:51:23 UTC 2005
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:
More information about the fedora-devel-list
mailing list