I recently added the nntp use flag for evolution. When I did emerge -puDN, only evolution came up, not evolution-data-server (e-d-s). e-d-s also has an nntp use flag option, so I added it too. This way both evolution and e-d-s were recompiled. There are two questions wrt this situation. 1) should evolution be allowed to recompile with an inconsistent use flag from e-d-s? Or should portage complain about the inconsistency? 2) should there be a message printed at the end of an emerge of evolution or e-d-s showing which use flags were not applied. Sometimes, users do not know all options that could be applied. There is no opportunity to run `configure --help` to turn on or off switches. IMO, emerge should fail when evolution's use flags are inconsistent with e-d-s and an appropriate warning message appear. And, since the two products are so closely linked, maybe consider having a meta evolution package that would handle both products together and have common use flags. I am happy to help with this in testing, etc.
emerge --newuse -uD world is proper way to proceed after changing USE flags... I don't quite understand what are you after here; if you have problems with compiling something then post the ebuild version and error messages you get.
Sorry I was not clear. Assume both evolution, and evolution-data-server were compiled with no use flag modifications. The default is -nntp for both. I want to access nntp with evolution, so I add mail-client/evolution nntp to package.use. When I update with emerge, only evolution is updated, not evolution-data-server. However, evolution-data-server should share the same flags as evolution otherwise things might break. Therefore, I suggested that a check be made to insure that both evolution and e-d-s share common use flags otherwise emerge should post an error. It makes no sense to compile evolution +nntp and evolution-data-server -nntp.
I provided the necessary information, so am reopening this bug.
I'm not sure I agree. There's no particular reason why the two have to have the same use flags. Especially, it makes sense to have e-d-s have use flags that evo doesn't, because more and more programs are using e-d-s besides evo. It might make sense to require e-d-s to have every flag evo does, or have evo fail. I'll think about it. A better solution in this case would be to take out the nntp use flag for e-d-s, since it doesn't pull in any deps. I'll make this change in the 1.7.x versions (part of 2.15), and well consider other changes for 2.14.x
If the flag is not needed for e-d-s, then I am incorrect. It's just a very odd thing to compile both halves differently. Would you do the same with ldap? I just think it's important to be consistent. JM2C.
It's not the the flag makes no difference (it appears to), but that it doesn't pull in any dependencies. There's no reason to disable it if it doesn't pull in any deps. ldap, on the other hand, does pull in deps, to the flag should probably stay.
dang, any updates on this bug?
Sorry, I completely forgot. I've pulled nntp from e-d-s 1.9.x. I'm undecided if we should pull it from 1.8.x, but I don't really care either way.
Daniel: I'm not sure that it's necessary to remove USE flags when they do not add dependencies. Why don't you like solution to keep nntp USE flags both in evolution and evolution data server and use `built_with_use -a gnome-extra/evolution-data-server nntp || die` in evolution to check that eds is actually built with nntp? I understand that die is very bad for interactivity but in this particular case it's best solution while USE depth does not enter portage... If you wish I can submit patches or modify evolution ebuild as necessary.
I absolutely hate built_with_use checks, and I won't put them in unless it's absolutely necessary, sorry. In this case, however, there doesn't appear to be a downside to removing the nntp use flag from e-d-s, and there's a huge downside to adding a built_with_use to evo, so I think we have the correct solution. Use-based deps aren't even needed in this situation, because there's no reason for nntp to be optional in e-d-s, that I can see.
I vote for keeping the current solution (that is e-d-s without nntp use flag and evo with nntp use flag) for the reasons mentionned in comment #4 and close this bug.
I agree.
