Bug 211250 - RFE: Make protectbase or priorities default
Summary: RFE: Make protectbase or priorities default
Alias: None
Product: Fedora
Classification: Fedora
Component: yum
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-10-18 03:16 UTC by Christopher Stone
Modified: 2014-01-21 22:55 UTC (History)
0 users

Clone Of:
Last Closed: 2006-10-18 11:42:47 UTC

Attachments (Terms of Use)

Description Christopher Stone 2006-10-18 03:16:09 UTC
Description of problem:
There are several repositories (which shall remain unnamed) which override
packages found in the Fedora Core and Fedora Extras repository.  This
essentially creates the following problems:

1) Such repositories essentially "fork" the Fedora distribution and create their
own distribution.
2) Such forking creates an extra burden on the entire Fedora community because
now they have to support multiple distributions instead of a single common
standard distribution.
3) People often run into yum upgrade conflicts when using such repositories
4) Debugging problems from users who use such repositories require that users
disable and remove all packages from such repository in order for us to properly
debug a problem against a standard base Fedora reference package suite.

Obviously such packages are extremely harmful to Fedora and the community, and
we should strive to discourage such behavior from these repositories any way we can.

To fix this problem there have been a couple of suggestions:
1) Make the 'protectbase' yum plugin the standard default behavior for yum and
instead make a plugin to allow other repositories to override base packages.
2) Instead of using protectbase, use the 'priorities' plugin for yum found here:
http://danieldk.org/code/yum/ built into yum.

It was suggested by Angel Marin <anmar@anmar.eu.org> to use priorities instead
of protectbase, here is his quote:

"I'd suggest the 'priorities' [1] plugin instead of the 'protectbase' as
it allows more flexible configurations.

With the priorities plugin and a careful configuration, it's almost
impossible to mess up a system no matter which repositories you add. I'd
hardly use any third party repositories in any distribution (fc, rhel,
centos) without 'priorities' (or at least protectbase) installed, you
get the best of both worlds :)

[1] http://danieldk.org/code/yum/"

Comment 1 Jef Spaleta 2006-10-18 08:01:55 UTC
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 

Comment 2 Christopher Stone 2006-10-18 08:20:34 UTC
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.

Comment 3 Seth Vidal 2006-10-18 11:42:47 UTC
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

Comment 4 Karen Pease 2006-10-18 15:29:34 UTC
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 
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. 

Comment 5 Christopher Stone 2006-10-18 15:48:18 UTC
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?

Comment 6 Alan Cox 2006-10-18 17:03:55 UTC
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.

Comment 7 Christopher Stone 2006-10-18 17:12:27 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.