yum RFE

[Nicolas Mailhot]

Le mercredi 18 octobre 2006 à 14:52 -0700, Toshio Kuratomi a écrit :
> On Wed, 2006-10-18 at 12:38 -0500, Josh Boyer wrote:
> > On Wed, 2006-10-18 at 13:15 -0400, Greg DeKoenigsberg wrote:
> ether it should be enabled by default or not... dunno.
> 
> It's sensible to include the plugin to aid intermediate and advanced
> users in mixing repositories.  But only with default off.
> 
> The end goal, as far as the novice user is concerned, is to install a
> piece of software 

Ok

> and be able to use it on their system.

Which implies not breaking said system with core replacements

>  Instead of trying to protect users
> from themselves (something that's doomed to fail -- people are clever
> enough to outsmart any roadblocks we put in place even if they don't
> understand why those roadblocks were there in the first place) we need
> to work with the greater community of packagers to diagnose why things
> are failing and get them fixed.

Fixing things so atrpms doesn't break some setups or people don't have
to go atrpms is certainly the priority.

*However* blindly accepting any command in Yum just because in the end
the user will do whatever he wants is not ok. We *are* protecting people
from themselves. People *expect* the system to warn them when they're
about to do something stupid. Need I remind you we're not running as
root by default for example?

Also, protectbase is far from being as restrictive as it could.
Typically users go to third party-repositories for one or two specific
needs, and then pull all sorts of unrelated packages because declaring a
repo exposes all its contents. A very useful yum restriction would be to
allow a repo only for a specific package list (pulling dependencies as
needed from the same repo, provided they can't be satisfied by a more
trusted one).

And yes ultimately the repo owner can poison his packages to rewrite the
repo setup, but :
1. most repo owners are responsible people which won't ever do this
2. *that* would be ground for official Fedora blacklisting
3. a package can do all sorts of other things on the system, we've never
refused to do anything because some other third-party package could
disable it (because in that case we wouldn't setting any policy)

Regards,

-- 
Nicolas Mailhot