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@centos.org http://lists.centos.org/mailman/listinfo/centos
KB, please don't top post.
</hides>
On Wed, Apr 6, 2011 at 4:06 PM, Karanbir Singh mail-lists@karan.org wrote:
<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@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
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 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.
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.
On Wednesday, April 06, 2011 03:22:48 PM Lamar Owen wrote:
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.
You wouldn't want to store the actual packages in the DB though... Instead, you'd store paths to the files. When new updates come in, download them, insert the records for a consistent view and so on. Then, have a background process, or even triggers, clean up the files that are no longer needed... However... (see below)
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.
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...
Peter.
Peter A wrote:
On Wednesday, April 06, 2011 03:22:48 PM Lamar Owen wrote:
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
<snip>
Instead, you'd store paths to the files. When new updates come in, download them, insert the records for a consistent view and so on. Then, have a background process, or even triggers, clean up the files that are no longer needed... However... (see below)
<snip>
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...
Ah, yes, sort of like, well, a real version control system.
mark, who used to be expert with PVCS, and could do all this
On 4/6/2011 2:52 PM, m.roth@5-cent.us wrote:
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...
Ah, yes, sort of like, well, a real version control system.
mark, who used to be expert with PVCS, and could do all this
Doing it with one instance is one thing - and I really wish yum could at least be told to ignore packages newer than a reference timestamp so it could reproduce updates even when new things have been added to the repos. But that's not the issue here - not even that would held with out of sync mirrors unless you can control the order of transfers.
Les Mikesell wrote:
On 4/6/2011 2:52 PM, m.roth@5-cent.us wrote:
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...
Ah, yes, sort of like, well, a real version control system.
mark, who used to be expert with PVCS, and could do all thisDoing it with one instance is one thing - and I really wish yum could at least be told to ignore packages newer than a reference timestamp so it could reproduce updates even when new things have been added to the repos. But that's not the issue here - not even that would held with out of sync mirrors unless you can control the order of transfers.
Nope. PVCS had (has?) both "labels" and "tags". We'd tag something as a given release, and you exported by tag to get the full release as of that date. You wouldn't put the tag on until everything had been promoted, and the system locked, then gang tag everything that was, say, labeled "production".
mark
On 4/6/2011 3:49 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
On 4/6/2011 2:52 PM, m.roth@5-cent.us wrote:
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...
Ah, yes, sort of like, well, a real version control system.
mark, who used to be expert with PVCS, and could do all thisDoing it with one instance is one thing - and I really wish yum could at least be told to ignore packages newer than a reference timestamp so it could reproduce updates even when new things have been added to the repos. But that's not the issue here - not even that would held with out of sync mirrors unless you can control the order of transfers.
Nope. PVCS had (has?) both "labels" and "tags". We'd tag something as a given release, and you exported by tag to get the full release as of that date. You wouldn't put the tag on until everything had been promoted, and the system locked, then gang tag everything that was, say, labeled "production".
Pretty much every version control system can do that, but I don't think any of then will work when you have a partially-rsync'd file copy of the repository that only has part of the tags you are trying to get and nothing to tell it they aren't all there.
instead, what I think would make more sense would be a modified repo architecture where the current repoinfo file is versioned, and there's a master file which refers to the name of the 'current' version.
so, to update the repo, you first copy all the new packages, and the new versioned repoinfo file(s), then you atomically update the master file to point to the new one, then some standard interval like 24 hours later, you clean up the old stuff
to do a yum update, you atomically read the master file once, and then read the versioned repoinfo etc and do your thing.
you have to bring up this new 'versioned' structure of the repo metadata in parallel with the current structure, so existing yum clients continue to work as-is with the existing warts for the foreseeable future.
note I wrote the above without refreshing my rather rusty and vague memory about the structure of a repo and its metadata.
[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.....
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Gilbert Sebenste Sent: Wednesday, April 06, 2011 4:03 PM To: centos@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?
-
Gilbert Sebenste -
John R Pierce -
Karanbir Singh -
Lamar Owen -
Les Mikesell -
m.roth＠5-cent.us -
Peter A -
Rudi Ahlers -
Sorin Srbu