On Sun, 2006-07-02 at 08:33 -0500, Johnny Hughes wrote: > On Sun, 2006-07-02 at 14:12 +0200, Dag Wieers wrote: > > On Fri, 30 Jun 2006, Robert Spangler wrote: > > > > > On Thu June 29 2006 16:20, Bart Schaefer wrote: > > > > > > ><snip> > > > > What's the correct incantation for this? > > > > > > Goto your /etc/yum.repos.d and edit CentOS-Base.repo and do the following; > > > > > > under [base] add > > > exclude=firefox > > > > > > Under [centosplus] add > > > includepkgs=firefox > > > > In fact the protectbase plugin should understand that if you force a > > package out of base, that this is the desired behaviour and pull new > > packages from the repository it came from. > > > > This behaviour would allow people to override protectbase and make it > > permanent. Yum in that case needs to display what it is doing so there's > > no chance of misinterpreting the behaviour. > > > > Kind regards, > > -- dag wieers, dag@xxxxxxxxxx, http://dag.wieers.com/ -- > > [all I want is a warm bed and a kind word and unlimited power] > > I agree that would be desirable behavior ... now, how to program that, > no idea :) > > If there is someone out there who is smart enough to make that happen, > please do :) I don't see it happening in the current context. AFAICT, yum and/or rpm "forget" where an installed package came from. Correct? If so, consistent update behavior depends on 1) packages that didn't exist in repo A and were obtained from repo B never appear in a later version in repo A, 2) the naming conventions used to distinguish packages among repos (.rf, .plus, ...) prevent a "match" process unless the "base name" and variations to it are "well known" to yum, and 3) extremely vigilant users ready to sling/retract "includepkgs" and "exclude" statements at a moment's notice. Sort of defeats the whole purpose of Yum. It may be that the number of and relationship between repos far exceeds Yum's basic design intent. Or maybe it's the style of usage? What this comes down to, IMO, is that the usage environment and scenario has changed (? or was never a match) sufficiently that an adequate specification of the "new" environment and requirements is needed. What I have seen here (and I look nowhere else) is a piecemeal approach as "issues" are discovered. I understand that this may be the "favored" method in the FSS world, but it remains woefully inefficient and leads to what we've been seeing. It would seem to require coordination and cooperation among repo maintainers, yum developers and "users" (in my mind, mostly CentOS developers/packagers and some of the more aggressive users). Since the "base data" is extremely "fluid" (my kindest terminology), meaning that a later version of any package can appear in any repo at any time and need to be included/excluded by any user, or not ... Only a re-visitation of the design considering all the current factors, desired use schema, .... can result in a "satisfactory" long-term solution. OTOH, things can continue as they are as only a select few individuals are caused any inconvenience (ignoring the folks who field the questions, those who wonder "why don't they search the archives before asking", ...). > <snip> MHO -- Bill
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos
