On Wed, Mar 08, 2006 at 04:10:12PM -0600, Troy Dawson wrote:
> Axel Thimm wrote:
> >On Wed, Mar 08, 2006 at 11:08:08AM -0600, Connie Sieh wrote:
> >
> >>On Wed, 8 Mar 2006, Jaroslaw Polok wrote:
> >>
> >>>Here at CERN for SLC4 in order to avoid such unpleasent surprises
> >>>we are using the yum protectbase plugin and label our repositories
> >>>as 'protected': ie any newer packages not coming from our repos
> >>>are excluded from yum transactions:
> >>>
> >>>- Maybe it would be worth including that plugin in
> >>>SL (and configure it by default to enable repo protections) ?
> >>
> >>We include that in the SLF site too.
> >>
> >>What do others think?
> >
> >
> >From a 3rd party's POV this is a very bad idea, as it breaks our
> >repos.
> 
> First off, it currently IS in the distro
> 
>  yum install yum-protectbase
> 
> It is not installed by default
> If you do install it, it does not have any particular repo setup by 
> default, you have to setup the config file yourself.
> 
> Why is it that way?
> To be honest, it is because of the 'Install Everything' people.  People 
> install everything, then complain because something is broken, so I have 
> to make sure even if every yum plugin is installed, it doesn't really 
> hurt anyone.
> The people who install everything also are usually the people who use 
> 3rd party repositories like Axel's or Dag's.
> If you use Axel's (or Dag's) repository, there might be something in 
> that repository that needs to update an existing package from plain 
> Scientific Linux.  If you have the protectbase plugin set to protect the 
> main scientific base, then you won't be able to install whatever it was 
> you wanted because of this dependancy.

It's worse, you probably will be able to install it, and the
assumption will be that the overlapping package has been
patched/updated/etc, which it will not. So you'll see the breakage at
run time only. And probably only when some specific feature is
required. As an example off the top of my head I remember the
perl-DateTime package that was not UTF-8 safe in the vendor's repo and
would break mythtv setups from epgs with UTF-8 content.

And the same is true for almost all updated packages in 3rd party
repos. The reasons for overriding a vendor's package is not usually
for the fun of the package itself, but as part of a dependency chain
requiring either a different build config or some patching.

I've had quite a lot of bug reports of this kind in Fedora space. Not
with the yum-protectbase, but with the --enable install foo methods
used, which will also not pull in the required updated packages. Any
method that effectively split off an arbitrary part of a repo and only
makes that visible to the depsolver can break the package within.

The net result is that people "half-enable" a repo, try something out
and either decide that the repo is crap since the software doesn't
run, or start making bug report w/o mentioning the partial enabling of
the repo.

> So ... in the end.  I could be persuaded to have the package 
> yum-protectbase protect scientific linux base and errata areas by 
> default.  But I really don't think having it installed by default is the 
> right way to go.

I'd prefer it the way it currently is. Some day it will slip again
into @Everything.
-- 
Axel.Thimm at ATrpms.net