I have lightning and thunderbird installed. According to bug #296306, enabling the lightning use flag for thunderbird means, that portage knows that I want to use lightning with thunderbird, and does not attempt the installation of thunderbird 3 (for which lightning lacks support). Now the problem is… well let me descibe it with the fields below: Reproducible: Always Steps to Reproduce: 1. Have mail-client/mozilla-thunderbird-2.0.0.23 and x11-plugins/lightning-0.9 installed. 2. Run (emerge --sync and) emerge -auDNtv world. Actual Results: lightning blocks thunderbird 3, and emerge fails. Expected Results: lightning blocks thunderbird 3, and emerge does not install thunderbird 3 for now. Portage simply should not fail. There is no reason why it can’t just leave thunderbird 2 on the system, until a compatible version of lightning comes out. masking thunderbird 3 in package.mask is no solution, since this would mean, that when a compatible version of lightning is available, one would miss it, and would have to manually check this each time. Instead of being able to rely on portage.
Newer portage versions handle this.
Ok, I found out, that apparently the also installed “enigmail” package seems to want thunderbird 3 in the first place. But then, thunderbird 3 itself is dependent on engimail on my system. So I have to mask both thunderbird 3.0 and enigmail 1.0, to get it to install anything.
(In reply to comment #1) > Newer portage versions handle this. How new? I tried this with portage-2.2_rc59! ^^
This is not difficult to solve. Simple emerge -C enigmail lightning && emerge -u mozilla-thunderbird with lightning and crypt useflag enabled.
(In reply to comment #4) > This is not difficult to solve. Simple emerge -C enigmail lightning && emerge > -u mozilla-thunderbird with lightning and crypt useflag enabled. Just as I expected, this wants to install thunderbird 3 and enigmail, but no lightning. Which is exactly the opposite of what I wanted to achieve. thunderbird 2 has no lightning use flag. guys, this can’t be... it should look like this: 1. I set “mail-client/mozilla-thunderbird lightning enigmail” in package.use. 2. I “emerge -auDNtv world”. 3. Portage finds thunderbird 3, but sees that the lightning use flag is not satisfiable for version 3. 4. Portage masks thunderbird 3, and chooses the latest non-masked version (2.0.0.23). Which already is installed. 5. Portage checks for (updated versions of) lightning and enigmail, and adds them to the list. 6. Portage lets me install the updates, not complaining about thunderbird 3. As it is right now, portage instead just ignores, that there is no compatible lightning for version 3, and wants to install thunderbird 3 and (the update of) enigmail. Which wrecks lightning. :(
At least I don’t have to also mask enigmail-1.0 anymore. But I still have to mask thunderbird-3.0. Which creates the problem mentioned in comment #0.
You forgot to post your `emerge --info cat/pkg'. I assume you're running ACCEPT_KEYWORDS='arch ~arch' there, in which case you cannot rely on sys-apps/portage to get a stable system at all, or you unmasked only x11-plugins/lightning and the verdict would be exactly the same. Either don't unmask packages or don't file bugs about the package manager breaking. :)
(In reply to comment #7) > You forgot to post your `emerge --info cat/pkg'. No I didn’t. You forgot to tell me. Because it’s not mentioned anywhere in the bug creation process, and i’m, you know, not born with it. ^^ I didn’t even know you could add a pkg in combination with --info. But a generic --info would have made sense. I will attach it. > I assume you're running > ACCEPT_KEYWORDS='arch ~arch' there, in which case you cannot rely on > sys-apps/portage to get a stable system at all, Strawman argument. I did not expect a stable system. I did expect portage to do its job. :) As yo see, it’s portage that does something wrong. Also, how are you going to fix any bugs at all, if you just call any bug a “that’s unstable, so we don’t have to fix it”. That way it will stay unstable forever, and you will avoid doing it forever. ;) (I’m not expecting you do do any work for anyone for free, but if you don’t want to do it, say so. I’m OK with that. Just means that by definition, then you’re no maintainer anymore. :) In conclusion: If it’s in portage, and not abandoned, every bug should be fixed. :)
Created attachment 213389 [details] emerge --info lightning mozilla-thunderbird enigmail
(In reply to comment #8) > (In reply to comment #7) > > You forgot to post your `emerge --info cat/pkg'. > > No I didn’t. You forgot to tell me. Because it’s not mentioned anywhere in > the bug creation process, and i’m, you know, not born with it. ^^ > I didn’t even know you could add a pkg in combination with --info. > But a generic --info would have made sense. I will attach it. The output of the version of sys-apps/portage that you use would have told you that [using a fake ebuild as example here]: = = = = = = = = = = = = = = = = = = = = = = = = = = >>> Failed to emerge app-misc/gentoo-fail-0, Log file: >>> '/keeps/gentoo/emergelogs/astrid/app-misc:gentoo-fail-0:20091218-143316.log' * Messages for package app-misc/gentoo-fail-0: * ERROR: app-misc/gentoo-fail-0 failed: * pkg_setup failed * * Call stack: * ebuild.sh, line 55: Called pkg_setup * gentoo-fail-0.ebuild, line 14: Called die * The specific snippet of code: * pkg_setup() { die "pkg_setup failed"; } * * If you need support, post the output of 'emerge --info =app-misc/gentoo-fail-0', * the complete build log and the output of 'emerge -pqv =app-misc/gentoo-fail-0'. * This ebuild is from an overlay named 'JeR': '/keeps/gentoo/local/' * The complete build log is located at '/keeps/gentoo/emergelogs/astrid/app-misc:gento o-fail-0:20091218-143316.log'. * The ebuild environment file is located at '/var/tmp/portage/app-misc/gentoo-fail-0/t emp/die.env'. * S: '/var/tmp/portage/app-misc/gentoo-fail-0/work/gentoo-fail-0' = = = = = = = = = = = = = = = = = = = = = = = = = = > > I assume you're running > > ACCEPT_KEYWORDS='arch ~arch' there, in which case you cannot rely on > > sys-apps/portage to get a stable system at all, > > Strawman argument. I did not expect a stable system. I did expect portage to do > its job. :) As yo see, it’s portage that does something wrong. When I wrote about a "stable system", I meant sys-apps/portage resolving dependencies for you in a convenient way. As it is, the steps you outlined in comment #5 will probably not be implemented soon - portage currently always picks the best unmasked version of a package and then works out what the USE flags mean, not the other way round. You can package.mask any =mail-client/mozilla-thunderbird-3* that do not support x11-plugins/lightning for now as a workaround. > Also, how are you going to fix any bugs at all, if you just call any bug a > “that’s unstable, so we don’t have to fix it”. That way it will stay > unstable forever, and you will avoid doing it forever. ;) > (I’m not expecting you do do any work for anyone for free, but if you don’t > want to do it, say so. I’m OK with that. Just means that by definition, then > you’re no maintainer anymore. :) You're confusing myself, a bug wrangler, with the package maintainers. Notice that the bug report still isn't assigned to its maintainers. I am here to assess bug reports and assign them if they're valid, not to fix bugs in just any package.
(In reply to comment #10) > The output of the version of sys-apps/portage that you use would have told you > that […] You’ve got a point there. :) Weird that I never noticed that... I always was under the assumption, that it was used without the pkg. > When I wrote about a "stable system", I meant sys-apps/portage resolving > dependencies for you in a convenient way. Ah, OK. :) > As it is, the steps you outlined in comment #5 will probably not be implemented > soon - portage currently always picks the best unmasked version of a package > and then works out what the USE flags mean, not the other way round. Ok, that was my first assumption too. But then I got misinformed by someone here on bugzilla telling me, that portage would handle this properly. And that’s why I opened the bug. I really hope this feature will be added in the future thought. Now I have to manually check which packages to unmask because their dependencies are now available, every time I sync portage and prepare to update the system. :( Which is very error-prone, because you often forget to think about yet another thing. > You're confusing myself, a bug wrangler, with the package maintainers. Notice I guessed something like that too. I meant it in a more general way. :)
Closing and marking as “might be implemented in the future, as it’s not a bug (yet) but a missing feature”. :)
