RDEPEND contains mail-mta/citadel which is not in the portage tree (bug 62119 seems to indicate that it's in the sunrise overlay). Packages in the portage tree shouldn't depend on overlays. Please remove that dependency. Sunrise should maintain its own copy of the virtual if they need packages from their overlay included.
+ 22 Apr 2011; Eray Aslan <eras@gentoo.org> mda-0.ebuild: + drop citadel from RDEPEND - bug 364445 +
Hey, that was a quick response. :) Thanks.
(In reply to comment #0) > RDEPEND contains mail-mta/citadel which is not in the portage tree (bug 62119 > seems to indicate that it's in the sunrise overlay). Packages in the portage > tree shouldn't depend on overlays. Depending is one thing, one-of depending is another. I don't really see a reason why a virtual may not do something like that, considering that the preferred dependency (which would be pulled in by the PM if none of the packages is installed) is in gx86 anyway. > Please remove that dependency. Sunrise should maintain its own copy of the > virtual if they need packages from their overlay included. Then any other overlay would contain its own copy, overriding the previous one and killing the packages in question.
(In reply to comment #3) > I don't really see a > reason why a virtual may not do something like that, considering that the > preferred dependency (which would be pulled in by the PM if none of the > packages is installed) is in gx86 anyway. The reason I accepted the bug is we can't keep track of what the overlays do. This one is rather straight forward but there are USE flags, version constraints etc to consider. Better to keep the official tree consistent and let the overlays keep their tree consistent as well by managing their own versions of virtuals. > Then any other overlay would contain its own copy, overriding the previous one > and killing the packages in question. Ehh? Surely not if they manage it correctly.
(In reply to comment #4) > (In reply to comment #3) > > Then any other overlay would contain its own copy, overriding the previous one > > and killing the packages in question. > > Ehh? Surely not if they manage it correctly. And how would "they" (whoever that should be) manage it correctly? Simple example: kde overlay and sunrise overlay, both with a mta, so both with a virtual/mta including main tree data and the mta from the overlay. Now user adds both overlays. One virtual/mta, e.g. from kde, will override the other, so if the user in this case installs the mta from sunrise, virtual/mta will still request another mta, since the kde one does not know about the mta from sunrise. How do you want to resolve this properly without doing it in the main tree?
> And how would "they" (whoever that should be) manage it correctly? Presumably, the email author will supply the revised virtual package. > How do you want to resolve this properly without doing it in the main tree? That way lies madness. We cannot cater to all overlays in the main tree. There are potentially too many of them. In any case, I don't think *DEPENDing on a package outside of the main tree is a good idea.
(In reply to comment #6) > Presumably, the email author will supply the revised virtual package. Sigh. s/email/package/
(In reply to comment #6) > > And how would "they" (whoever that should be) manage it correctly? > > Presumably, the email author will supply the revised virtual package. > > > How do you want to resolve this properly without doing it in the main tree? > > That way lies madness. We cannot cater to all overlays in the main tree. > There are potentially too many of them. In any case, I don't think *DEPENDing > on a package outside of the main tree is a good idea. First question: Any real argument against additional packages from overlays in *DEPEND? And second one still open: How do you want to resolve that example without doing it in the main tree?
http://archives.gentoo.org/gentoo-dev/msg_638e612675acbd39fc87b7d2e3ed50a7.xml + 24 Apr 2011; Eray Aslan <eras@gentoo.org> mda-0.ebuild: + add mail-mta/citadel back again, hopefully, for the last time +
