CentOS - Apr 2011 - CentOS 5.6 will not install due to Firefox error

Hello all,

Well, my local mirror now has CentOS 5.6! Yay! But, I cannot
get it to install. A "yum update" and a "yum --skip-broken"
yields me this:

--> Processing Conflict: firefox conflicts xulrunner >= 1.9.2.14
--> Finished Dependency Resolution
firefox-3.6.13-2.el5.centos.i386 from installed has depsolving problems
   --> firefox conflicts with xulrunner
Skip-broken could not solve problems
Error: firefox conflicts with xulrunner
  You could try running: package-cleanup --problems
                         package-cleanup --dupes
                         rpm -Va --nofiles --nodigest
The program package-cleanup is found in the yum-utils package.


Any ideas? All the packages seem to be there.

*******************************************************************************
Gilbert Sebenste                                                     ********
(My opinions only!)                                                  ******
*******************************************************************************

<top posting>

you need to wait for 5.6 to actually be released

- KB

On 04/06/2011 03:02 PM, Gilbert Sebenste wrote:
> Hello all,
>
> Well, my local mirror now has CentOS 5.6! Yay! But, I cannot
> get it to install. A "yum update" and a "yum
--skip-broken"
> yields me this:
>
> -->  Processing Conflict: firefox conflicts xulrunner>= 1.9.2.14
> -->  Finished Dependency Resolution
> firefox-3.6.13-2.el5.centos.i386 from installed has depsolving problems
>     -->  firefox conflicts with xulrunner
> Skip-broken could not solve problems
> Error: firefox conflicts with xulrunner
>    You could try running: package-cleanup --problems
>                           package-cleanup --dupes
>                           rpm -Va --nofiles --nodigest
> The program package-cleanup is found in the yum-utils package.
>
>
> Any ideas? All the packages seem to be there.
>
>
*******************************************************************************
> Gilbert Sebenste                                                    
********
> (My opinions only!)                                                  ******
>
*******************************************************************************
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>

>-----Original Message-----
>From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On
Behalf
>Of Gilbert Sebenste
>Sent: Wednesday, April 06, 2011 4:03 PM
>To: centos at centos.org
>Subject: [CentOS] CentOS 5.6 will not install due to Firefox error
>
>Any ideas? All the packages seem to be there.
Wait for the sync to complete in a few days?

-- 
/Sorin

On Wednesday, April 06, 2011 10:06:54 AM Karanbir Singh
wrote:
> On 04/06/2011 03:02 PM, Gilbert Sebenste wrote:
> > Well, my local mirror now has CentOS 5.6! Yay! But, I cannot
> > get it to install. A "yum update" and a "yum
--skip-broken"
> > yields me this:
 
> you need to wait for 5.6 to actually be released
I really really wish repositories would be ACID compliant.  Yeah, I know
they're not, but I've seen way too many issues with non-atomicity in
repository updates and syncs and their interaction with yum update.  If nothing
else raise a flag on the repo and essentially tell yum to go away until the sync
is finished.  Or sync the repodata last, and leave a couple of previous versions
of packages (helps for a yum downgrade, anyway).

I've seen it with Fedora, and with C6 it will have similar impact, since
yum-complete-transaction is present in the version of yum-utils upstream for C6.
That is, you might do a large yum update and have an issue, or crash, or the ssh
session goes down, or whatnot; yum-complete-transaction is supposed to rescue
your bacon in that circumstance; and it will as long as nothing has changed on
the repository, as I've used yum-complete-transaction a few times with
success.

However, if the repository changes between the yum update and the running of
yum-complete-transaction, the transaction completion will fail, since it goes
all the way back through the depsolver, and if the resulting transaction is not
identical to the failed one the transaction completion will fail.

Would be so nice to be able to do something like PostgreSQL's MVCC while the
repository is syncing newer updates; even nicer if a yum-complete-transaction
(run within x amount of time, of course) wouldn't change its transaction and
fail out....and it's incredibly difficult to reproduce this failure for a
meaningful bug report.

I know, not exactly on-topic, but a pet peeve of mine.....

On Wednesday, April 06, 2011 02:33:24 PM John R Pierce
wrote:
> On 04/06/11 7:56 AM, Lamar Owen wrote:
> > I really really wish repositories would be ACID compliant.
> 
> I concur, but I'm not sure how you'd do this, since some users will
be
> in process with an update under 1 state while the repo switches to the 
> new state, even if that state switch is instantaneous.
Pipe dream: MultiVersion Concurrency Control, like PostgreSQL implements it, but
for packages instead of regular tuples.  Hrmph, PostgreSQL BLOB/bytea support is
good enough to serve packages out of, now.....  A reader will always get
consistent data in an MVCC scheme.

Yeah, I know, I should know better.  But I was told that same thing years ago
when I first started advocating delta rpms.  Now we (well, not CentOS, but
upstream Fedora at least) have presto, and, yeah, it works great.

[Ah! Peter!  Back from the loonybin I see.... we're still using the sun QFE
boards and the Ex500 CPU cards, thanks again....]

On Wednesday, April 06, 2011 03:48:14 PM Peter A wrote:
> On Wednesday, April 06, 2011 03:22:48 PM Lamar Owen wrote:
> > Pipe dream: MultiVersion Concurrency Control, like PostgreSQL
implements
> You wouldn't want to store the actual packages in the DB though...
Instead,
> you'd store paths to the files.
I don't know..... brainstormed it, but haven't really set down to think
it through.  I think I might actually want to put the packages into bytea
fields, but populate actual table fields with metadata, and even build a
dependency structure or something similar.... would be a lot of work, that's
for sure.
> This is very different than the delta rpms though... delta rpms and all
that
> still works with a simple http server. For a mvcc you'd need a backend
to have
> an actual DB, scripting backend and such...
True enough.  Could be something for private mirrors serving internal users more
easily, and might even allow better control and rollout of updates.  For the
public mirror system it's not likely to happen, at least not until a simple
way using existing infrastructure can be devised.

Now if I only had free time.....