FC5 and Yum Plugins

[Jeff Spaleta]

On 12/31/05, Naheem Zaffar <naheemzaffar at gmail.com> wrote:
> Will this plugin allow packages to move from a protected core to a protected
> extras, and vice versa?
>
> After all That is a perfectly reasonable event.

That's one of the problems with the concept of protectbase... for
consistent operation across upgrades it would have to protect both
Core and Extras if it were turned on by default.. preventing 3rd party
repos from overriding even Extras. That's a very tight constraint on
3rd parties.

This is an absolutely pointless default plugin.  All it does is
encourage people to selectively use 3rd party repositories in a way
they were not designed or intended to be used. You either trust a repo
or you don't. Repos that want to be strictly compatible with
Core+Extras will choose to structure their offerings in a way that
makes protectbase moot. Users who want atrpms to be strictly
compatible with Core+Extras should go convince Axel to restructure. 
For 3rd parties who desire to offer replacement packages, atrpms,
newrpms and livna ( in at least the case of audacity ) this plugin
KILLS the intended purpose of the 3rd party repo and it WILL lead to
untested and undiagnosable problems related to delibrately holding
back replacement packages.  3rd parties have reasons for offering
replacements. You either trust the reasoning of the 3rd party repo or
you don't.  If you do not want to trust the 3rd party repo.. do not
use it for anything.

I do not believe users who delibrately go out of their way to
selectively pull crap from 3rd parties are worth "protecting". These
users are delibrately doing things that the repository maintainers do
not encourage nor recommend.  This project should not make default
settings that encourages users to abuse the intended purpose of 3rd
party repos.  The argument that this is a security measure.. is nuts.
Once you choose to pull any packages from a 3rd party you sure as hell
better trust the security practises of that 3rd party... scriplets can
do amazingly wonderful things..even with selinux enabled.  If you are
concerned about the security implications from nrpms or atrpms or
whatever.. you don't configure those repos for ANYTHING. The problem
is NOT overlap.. the problem is users are googling for crackrock quick
install instructions and finding "popular" instructions that
shortcircuit repository usage patterns recommended by the repo
maintainer.  Do not doubt for a second that in the future "popular"
recipe instructions will be created that tell users to turn this
feature off so as to make something like nrpms work. I find it
absolutely paradoxical that we are debating "protecting" users by
default from 3rd party vendors they have to go out of their way to
configure and enable to see on their system at all.

Is there any usage other than mythtv right now, that invovles
widespread selective use of a 3rd party repo?  Widespread as in you
can find a highly ranked google recipe that tells users to enable a
repo selectively?  All the mythtv users out there who want to
selectively pull mythtv from atrpms., should convince Axel to jettison
those packages off as a subrepo.. or stop using atrpms. Forcing a
default configuration option that breaks how 3rd party repos are
intended to work is the wrong solution.  For users who want to use a
repo selectively... yum already provides configuration directives to
handle updating sanely. They are called exclude and includepkgs. Sadly
the frelling recipe writers who are telling people how to add and use
3rd parties selectively are not telling people how to use the
configuration directives to narrow the scope of the repo. man
yum.conf. The original poster to this thread should take the time to
learn how to configure his atrpm's definition to encode the mythtv
packages selectively using "includepkgs" instead of looking to this
project to create a hack default policy which supports his
unrecommended package usage pattern.

-jef