Since now qmail depends on >=cmd5checkpw-0.30, on the it was pulled in. the problem is with the DEPEND of cmd5checkpw, that is !<qmail-1.03-r16. this causes portage to not be able to update neither of the package. Reproducible: Always Steps to Reproduce: 1. Have cmd5checkpw and qmail installed 2. emerge -uv world Actual Results: Calculating world dependencies ...done! [blocks B ] <mail-mta/qmail-1.03-r16 (is blocking net-mail/cmd5checkpw-0.30) [ebuild U ] net-mail/cmd5checkpw-0.30 [0.22-r3] 25 kB [ebuild U ] mail-mta/qmail-1.03-r16 [1.03-r15] -gencertdaily -logmail -mailwrapper -noauthcram -notlsbeforeauth (-selinux) +ssl 147 kB Expected Results: Calculating world dependencies ...done! [ebuild U ] net-mail/cmd5checkpw-0.30 [0.22-r3] 25 kB [ebuild U ] mail-mta/qmail-1.03-r16 [1.03-r15] -gencertdaily -logmail -mailwrapper -noauthcram -notlsbeforeauth (-selinux) +ssl 147 kB changing the dep on cmd5checkpw-0.30 from !< to >= solve the problem This really should be solved since it's preventing users from upgrading...
You have to unmerge the installed qmail version before you can update. Portage isn't able to do that transparently for you (yet).
How will i uninstall a service that i have to have online?! a 24/7 service?! The depend string should be changed!
Complain to portage guys... the dependency in correct. *** This bug has been marked as a duplicate of 79606 ***
(In reply to comment #2) > How will i uninstall a service that i have to have online?! a 24/7 service?! Usually you have a integration box, do the update and testing there, create binary tarballs and do the real update within your regular maintenance schedule, so the box isn't down longer than necessary.
i already talked to the portage guys. It was them that told me how to fix my problem! And if i don't have the money to have another box and only have one online box all the time? I can't update my system?!
Carlo, This isn't valid (nor is your duping). cmd5checkpw doesn't dep on qmail in anyway going by previous deps; you do *not* stick the "I hate <qmail-1.03-r16" into cmd5checkpw, you stick the equivalent in >=qmail-1.03-r16 So... this bug is valid. If there is an explicit reason you need to do the version restricting of qmail within cmd5checkpw, state so- right now the deps in that ebuild look wrong.
(In reply to comment #5) > And if i don't have the money to have another box and only have one online box > all the time? I can't update my system?! I wouldn't call that such a setup 24/7 ready. (In reply to comment #6) > Carlo, > This isn't valid (nor is your duping). I did not mark this as dupe, but invalid originally. > If there is an explicit reason you need to do the version restricting of qmail > within cmd5checkpw, state so- right now the deps in that ebuild look wrong. I suspect that the qmail maintainers know what they do when they force to unmerge an ebuild before updating. That there's no additional information is indeed suboptimal.
unless cmd5pwcheck is in *anyway* screwing with qmail during it's own compilation, the dep is invalid. Looks of things, cmd5pwdcheck is standalone, qmail calls it; if qmail needs >=0.30, qmail's deps should reflect it, not cmd5pwdcheck's. Not a question of suboptimal information, it's a question of proper deps; you state what you need within the package, you don't move chunks of your version reqs into your dependencies.
As far as I understand, the issue here is the !<mail-mta/qmail-1.03-r16 dependency on cmd5checkpw-0.30. Is this correct? If yes, then please take a look at bug 110064. qmail-1.03-r15 is not compatible with cmd5checkpw-0.30 and qmail-1.03-r16 is not compatible with cmd5checkpw-0.22 (the versions currently in portage). To prevent portage from updating cmd5checkpw, I've added the block dependency for <mail-mta/qmail-1.03-r16. cmd5checkpw itself doesn't depend on qmail, so changing it to >= isn't valid.
Exactly the issue. The block shouldn't be in cmd5pwcheck. The version that qmail requires, should be _strictly_ in qmail's deps, not reversed, as it is now. The relationship here is that a specific qmail version requires a specific cmd5pwcheck version cmd5pwcheck requires nothing of qmail, as such it shouldn't have any qmail deps (let alone a blocker). So... like I said, tiz invalid.
Can you show me a way to prevent portage from trying to upgrade cmd5checkpw if qmail-1.03-r16 is not (being) installed? Just leaving the dependency on qmail will update cmd5checkpw, as it doesn't check the dependencies of the installed qmail (which might be -r15).
After talking to ferringb on IRC, I removed the block dependency and changed the cmd5checkpw dependency on qmail-1.03-r15 to <0.30. Lets hope this helps.