On 12/31/05, Naheem Zaffar <naheemzaffar@xxxxxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
