FC5 and Yum Plugins

[Jeff Spaleta]

On 1/2/06, Horst von Brand <vonbrand at inf.utfsm.cl> wrote:
> Perhaps the system should be marked "tainted" when installing third-party
> packages, like the kernel is for binary modules...

Who benefits from marking a system as tainted when 3rd party packages
are installed and how do they benefit?  I understand how taint is used
in the context of kernel modules.. I do not see how taint is useful
from a packaging system persepective since the scope of the packaging
system is so much wider when it comes to potential problems. Are we as
a project going to say "sorry package system is tainted, closing
bugreport as wontfix"?
Are we going to taint someone's system because they are using a test
version of Xorg subpackages from mharris's people.redhat.com at
mharris's explicit request? Are we going to taint systems for using
updates-testing?  Or for using a few packages out of rawhide when
testing to see if a bug is fixed?  I just don't get how tainting a
system because a few non-standard packages are installed helps anyone,
especially since we have no child-safe way to "downgrade" back to
standard packages after the system is tainted.

If the problem is users are unware that certain repos overlap before
they start using them and would prefer to use repos in a way that did
not overlap Core. Then the solution is to provide approprate
notification mechanism which makes users aware before they install
packages from overlapping repos, not to taint their system after the
fact.

I would prefer instead per package notification when the to be updated
package has a different signing key then the installed package and let
the user decide as to whether or not to let the package update move
forward.   Can this sort of notification be added to yum's review list
in a compact and easily digestable way.. i have no idea.  I'm sure the
sig comparison would slow yum down so I'm sure it would be an
unpopular feature among segments of the userbase.  This notification
mechanism could be extended to cause a transaction failure for
automated updates, similar to a missing dep failure and users can use
scripts similar to the scripts in the wiki, which work around broken
deps to do partial updates, to do partial updates which do not cross
the signing key barrier and to log package updates that do cross the
signing key barrier for later inspection.  Once notified about package
updates that change signing keys, users can choose to use
exclude,includepkgs per repo in their configs to prevent that
situation from happening in the future for those particular packages.

-jef