FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 11-22-2009, 06:55 PM
Jim Perrin
 
Default What's wrong with yum-priorities?

On Sun, Nov 22, 2009 at 2:27 PM, Dennis Kibbe <dennisk@sahuaro.us> wrote:
> "The upstream maintainer of yum, Seth Vidal, had the following to say
> about 'yum priorities' in September 2009:
>
> Gosh, I hope people do not set up yum priorities. There are so many things
> about priorities that make me cringe all over. It could just be that it
> reminds me of apt 'pinning' and that makes me want to hurl."
>
> This note was placed on the wiki (PackageManagement/Yum?Priorities)
> without any explanation why yum-priorities isn't a good idea.
>
> yum-priorities doesn't appear in RHEL 5.4 but protectbase does. Is that
> the better choice and if so why?


It's not really yum-priorities, so much as what it does and how it acts.

In a perfect world, you would not need to add additional repositories
to get all the software you want. However that's rarely the case.

What ends up happening is that you have multiple repositories that
provide the same thing, sometimes under different names. You end up
mixing dependencies between repositories, so some things are
protected, some pull in deps from the wrong repository... fire and
brimstone, dead rising from graves, dogs and cats start living
together. The whole mess introduces some really odd logic edge cases
for yum that should in theory never be encountered. It's basically a
software solution to a management problem.

If you're careful about what you're doing, it's fine. If you enable
every single repository you can find for centos, it's going to end up
causing you some issues.

The long and short of it boils down to how rpm is implemented, how
different packagers package things, and how ignorant the average user
wants to be to the internal workings of the system. Most folks just to
have it work, end of story. Yum gets caught in the middle, and
priorities, while good, is a hack that allows user freedom that comes
with some really ugly thinking.

--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-22-2009, 08:31 PM
Les Mikesell
 
Default What's wrong with yum-priorities?

Akemi Yagi wrote:
> In my humble opinion, the
> wiki article should provide ample explanation. Failing that, it should
> at least offer alternative methods (for example, use of exclude= etc
> ?). If not, it would be basically saying, "do not use 3rd party
> repositories".

You can't escape the fact that when you use 3rd party repositories that do not
coordinate their package names and dependencies, having a working system is just
a matter of luck and chance. Or that when the base repositories exclude
packages by policy, that you will be forced to use 3rd party repos. So, good luck.

I generally leave the extra repos disabled in the yum configuration and
install/update the packages I want from them with:
yum --enablerepo=reponame install packagename
but there's still a chance that one of these packages or something pulled as a
dependency will cause subsequent conflicts.

> People come to this page because they need/want/have
> to resort to 3rd party repos. When asked in the CentOS forums, I refer
> them to the Repositories article and I continue to advise them to use
> the priorities plugin.

It doesn't matter how you do it. There is still a chance that a file included
in a 3rd party package that you install will subsequently be included in a base
package update. And then you'll have the conflict regardless of any way you try
to control the priorities. An example now would be if you had installed
something that required libgcrypt11 from ATrpms. Now the
/usr/lib/libgcrypt.so.11 file will conflict with an update to the stock
libgcrypt-1.4.4-5.el5.i386.rpm package.

--
Les Mikesell
lesmikesell@gmail.com

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-22-2009, 09:00 PM
"Mike A. Harris"
 
Default What's wrong with yum-priorities?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Les Mikesell wrote:

>> People come to this page because they need/want/have
>> to resort to 3rd party repos. When asked in the CentOS forums, I refer
>> them to the Repositories article and I continue to advise them to use
>> the priorities plugin.
>
> It doesn't matter how you do it. There is still a chance that a file included
> in a 3rd party package that you install will subsequently be included in a base
> package update. And then you'll have the conflict regardless of any way you try
> to control the priorities. An example now would be if you had installed
> something that required libgcrypt11 from ATrpms. Now the
> /usr/lib/libgcrypt.so.11 file will conflict with an update to the stock
> libgcrypt-1.4.4-5.el5.i386.rpm package.

This exact problem occurred with java-1.6.0-openjdk, when it was
originally part of the EPEL addon repository, but then Red Hat released
it as an official part of RHEL with the 5.3 release (IIRC). The problem
this caused users of the EPEL package, was that the Red Hat openjdk was
an _older_ version of the package, and did not come with the web browser
plugin. The EPEL repository withdrew their package so as not to
conflict with the Red Hat packages. As a result, people whom found the
EPEL openjdk browser plugin worked fine for what they need now lost
their plugin leaving the following choices:

1) Use the Red Hat openjdk and not have a browser plugin.

2) Install Sun or IBM Java instead.

3) Remove the official Red Hat openjdk, get a copy of the original EPEL
openjdk and rebuild it for yourself, and use that.


I've used multiple repositories on various OS releases for a while now,
and you do need to use some creative yum configuration to try and keep a
clean system when doing so, but unfortunately no configuration is likely
to ever completely prevent all possible cross-repository problems that
could occur. ;o/

The best we can hope for, is that in future releases, the primary
official repository continues to get larger and larger, and that any 3rd
party repositories work more closely together to resolve potential
conflicts and other issues.


- --
Mike A. Harris Website: http://mharris.ca
Google Wave: mike.andrew.harris - at - googlewave.com
https://identi.ca/mharris | https://twitter.com/mikeaharris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFLCbRh4RNf2rTIeUARApoVAJ97GMZGqFhmO9+OJlBets mvws6XPgCeNmVQ
DvgL6doOsH+ns0m+9QrEigY=
=TMnJ
-----END PGP SIGNATURE-----
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-23-2009, 02:27 AM
R P Herrold
 
Default What's wrong with yum-priorities?

On Sun, 22 Nov 2009, Dennis Kibbe wrote:

> "The upstream maintainer of yum, Seth Vidal, had the following to say
> about 'yum priorities' in September 2009:
>
> Gosh, I hope people do not set up yum priorities. There are so many things
> about priorities that make me cringe all over. It could just be that it
> reminds me of apt 'pinning' and that makes me want to hurl."
>
> This note was placed on the wiki (PackageManagement/Yum?Priorities)
> without any explanation why yum-priorities isn't a good idea.

Hi, Dennis

That page is outlinked from the general discussion on
Respositories, which runs through a discussion of
'exclude' and 'includepkg' as earlier options to consider
before these two non-stock install addons to yum that you
mentioned.

The problem with priorities, and pinning generally, is that it
cannot anticipate the growth of package dependencies, and
tries to solve with a static rule, a shifting problem. It may
work to get what is initially wanted, but it is a durable
solution, nor the right solution, because eventually, some
combination of enhanced weighting will cause an unintended
consequence, blocking some more important upgrade [a
point version bump, or worse a security async update].

We see it a lot in the IRC channel with people who don't or
won't read, and with the intermitent availability of some
non-CentOS archives, and yet want the system to solve
integrating encumbered sound driver codecs and extensions.
They do, sometimes withthis approach, or forcing or much worse
--nodeps, and later have the 'wheels come off' when some
library dependency on a main archive is blocked by an upgrade
path not anticipated or tested by the adjunct archive
maintainer.

It is usually safe to drill in a binary package out at the
leaf nodes from an external archive -- but these encumbered
packages have a witches brew of libraries they need as well,
and when upgrades on the main line are issued, one can end up
with an unsolvable set of dependencies for the old, and
requirements by the new.

'priorities' falls over and dies at that point from
self-induced dependency hell, and CentOS is blamed for it in
the back splatter. I was the wiki article editor who
initially added that caveat section, after seeing priorities
being pushed as the 'best' alternative.

It is not. It is more like Russian roulette without peeking
at the state of the chamber, for your installation. The
mentioned 'exclude' and 'includepkg' approach is more correct,
but also requires reading the yum and rpm man pages, and
gaining some understanding of dependencies.

-- Russ herrold
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-23-2009, 03:22 AM
Les Mikesell
 
Default What's wrong with yum-priorities?

R P Herrold wrote:
> 'priorities' falls over and dies at that point from
> self-induced dependency hell, and CentOS is blamed for it in
> the back splatter. I was the wiki article editor who
> initially added that caveat section, after seeing priorities
> being pushed as the 'best' alternative.
>
> It is not. It is more like Russian roulette without peeking
> at the state of the chamber, for your installation. The
> mentioned 'exclude' and 'includepkg' approach is more correct,
> but also requires reading the yum and rpm man pages, and
> gaining some understanding of dependencies.

_And_ a crystal ball to anticipate uncoordinated future changes by different
parties in a single namespace and file tree. The only ways this can be solved
is to either have a single repository where nothing is excluded by policy and
names and files are coordinated, or to delegate out package and file namespace
to repositories that can't coordinate to keep them from conflicting. Neither of
these seem very likely to happen.

--
Les Mikesell
lesmikesell@gmail.com



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 11-23-2009, 08:31 AM
Kai Schaetzl
 
Default What's wrong with yum-priorities?

Well, I think reality is that most of us have had very good experience
with yum-priorities. There is no thing as absolute security.
And I'm going to continue to use it, it certainly allows for a more fine-
grained control than protect-base.

Kai

--
Kai Schätzl, Berlin, Germany
Get your web at Conactive Internet Services: http://www.conactive.com



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 10:42 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org