On 1/2/06, Horst von Brand <vonbrand@xxxxxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
