On 23/08/10 14:47, James Antill wrote: > Personally I recommend not using rpmforge, and instead just using > repositories that don't require yum-priorities to make sure your > system isn't corrupted by accident. Aha. But do such things exist? How do I distinguish a good repository from a bad one? Specifically, I'd be interested to know what's recommended for CentOS and RHEL - there's EPEL but we found it often just didn't have the packages we needed. Besides, if I were the the maintainers of a repository like RPMforge, I wonder how I'd tell if I'd introduced a potentially bad dependency like the one under discussion? If yum can't tell me, are there other tools which can? >> Firtly, the fact that yum+YP hides packages so completely they don't seem to be >> present can be confusing, and it'd be nice if that could be fixed so that >> --showduplicates will report the presence of packages which won't be installed >> because of YP. > > We noticed this was a problem (excludes can't be seen), and one > solution we came up with is to show something is being excluded in > "repolist". > Eg. > > % yum repolist | fgrep chrom > fedora-chromium Chromium web browser and deps 6 > % yum repolist -x v8 | fgrep chrom > fedora-chromium Chromium web browser and deps 5+1 > > ...the idea being that whenever people had dep. install problems we > always asked to see their repolist. > > If you want to play with a newer yum, you can try: > > http://repos.fedorapeople.org/repos/james/yum-rawhide/ Ok, potentially useful, although if I need to use an unreleased version of Yum, that makes it hard to use in my case. >> However, the bigger problem is that yum does *not* seem to be able to detect the >> kind of unresolvable dependency problem I experienced. Therefore it happily >> starts the update process, only to abort with an error half way through, leaving >> my system essentially broken. Neither does yum check-update warn me about this >> risk. > > I'm pretty sure this isn't true, there are roughly 6 stages for an > install/update: > > 1. Processing the argument. > > 2. Internally resolving dependencies. > > 3. Show what will happen to the user, and asking for confirmation. > > 4. Asking rpm to check that everything is fine (test transaction). > > 5. Asking rpm to run the transaction. > > 6. Running post transaction stuff. > > ...I'm pretty sure yum is stopping at #2 for you, which is fine. No - if it was, that would indeed be much better. This happened twice, on two similar machines, so I got the chance to verify that. It got to the prompt, i.e. #4, and there was no indication anything was wrong, so I let it go ahead. After upgrading a few tens of packages there was then a message reporting the unresolvable dependency and a suggestion that I use "yum update --ignore-broken" (and I am not sure if this is good advice). Does yum transact an entire upgrade and perform a complete roll-back to the pre-upgrade state on failure? As I recall, it didn't - some packages were installed, and some weren't. If I am mistaken and there is a transaction protecting the whole upgrade, this is better than I expected, but I don't think this was made clear to me afterwards. On the other hand, if only individual packages are transacted, this is a painful place to put to the poor user, who has been taken past the point of no return and has some painstaking detective work to do in order to finish the job. Cheers, N _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
