Bug 211250

I completely and utterly disagree that turning on any functionality by default
which changes how 3rd party repositories operate is going to help protect anyone
from 3rd party packaging irregularities.  In fact in the long term such a harsh
punative measure against 3rd party repo operation will actually make it more
difficult for users who want flexibility in their package mixing.

This isn't the first time this thought has come up... troll fedora mailinglist
archives a bit.

All we are going to do be using protectbase or a restrictive priority policy by
default is to encourage 2rd party repos to disable these default settings using
scriptlet action in their own release packages.  For example if I run the very
popular  rpms-that-will-kill-you-at-100-paces.net repository. I could very
easily offer a rtwkya100p-release package which via scriptlet action tunrs off
the default configs which prvent my kernel package from installing. And I can
make that specific -release package a hard requirement for any of my repo's
package. If as a repo maintainer I want my users to have my versions of the
package I have the ability to force it.

What you are proposing is a technical arms race and you aren't fixing the
underlying problem which is ultimately a difference in opinion on what role
individual addon repositories should be providing.  Strong arming 3rd party repo
maintainers into changing how they run their repos will not work, you are only
going to continue the rift between those repo maintainers in the fedora
contributor community if you attempt to enforce your opinion as default policy.

We aren't talking about keeping 5 year olds out of the medicine cabinet,
pretending that we can fix this by putting a tamper proof cap on yum by default
is only going to inspire people to subvert the technical measures making them
useless for everyone.

Keep protectbase as optional... keep priorities as optional... if you don't they
won't be very useful for anyone for very long.. because the 3rd party repo
maintainers will find a scripted means to disable these features if they get in
the way of expected user/repository interaction.


-jef"watches as about a year of forward progress in communication with 3rd party
repo maintainers is undone"spaleta 

If hard-coded into yum, the 3rd party repository would have to create their own
fork of yum and override yum itself which they would not be able to do because
yum would prevent that.  While it should still be possible, it should be very
clear to the user what she is getting into by displaying warnings about the
consequences of enabling such a repository.

You have been talking with 3rd party repositories which fork Fedora for about a
year and absolutely no progress has been made as far as I can tell.  There is
nothing to be "undone".  After so much talk and no progress, it seems to me that
we *are* dealing with five year olds.

So Jef, are you suggesting we continue with these talks to try and solve the
problem?  You did not mention any other possible solution.  If these talks have
truely been going on for almost a year and no progress has been made (as far as
I can see, correct me if I'm wrong), I do not see any other alternatives than to
modify yum to try and prevent this type of behavior as much as possible.

no. This is a plugin for a reason.

It will complicate and confuse things for users if what they expect to happen
when they add a new repo does not.

and it is utterly trivial to circumvent as all they have to do is label the 3rd
party repo as part of the 'base' that they want to protect.

So we'd be adding work for no actual gain

Why is it that so much of yum's functionality is in plugins to begin with?  I 
mean, seriously -- what's up with downloadonly and allowdowngrade being 
"plugins"?  It's not like you're going to accidentally use them.  If you're 
trying to downgrade something, you have a darn good reason.  Same with 
downloadonly. 
 
I think the whole point here *is* to complicate it for users who try to add a 
repo that overrides FC packages, while causing no problems for users who try 
to add a repo that doesn't override FC packages.  I think the point is to make 
sure that anyone who adds such a repo *knows what they're doing*. 
 
Labeling a third party repo as part of the 'base' is unscrupulous enough that 
even your average user would have a problem with it.  Picture such a yum 
change as a big, flashing warning sign -- a demonstration of what FC views as 
unacceptable.  Sure, you can circumvent it with tricks, but you'll *know* that 
you're circumventing what FC views as acceptable -- and if you do that, you 
better expect grief from FC people. 
 

I agree with Karen here.

We **WANT** it to be "utterly trivial to circumvent".

You are missing the point Seth.

The point is that the user must actually run a command or install a plugin in
order to allow a repository to do this.  Once this plugin is installed, a
warning can be printed out to the user to lets the user know the consequences of
doing this.

Why are you closing this bug in less than 24 hours of it being opened without
hearing any discussions on the topic from anyone?

I don't see it makes a difference at all, if it was on by default then the next
round of scripts for the problem repositories will just %script turn it off in
their setup packages.

Its not a useful way to deal with a political question.

I have made a suggestion on the fedora-packaging mailing list for the packaging
comittee to create a review process for 3rd party repositories and add a wiki
page which illustrates which repositories play nice and which do not.  Perhaps
this is a better approach to take.