>>>>> On Sat, 23 Apr 2011, Thomas Sachau wrote: > If e.g. kde and sunrise overlay both provide an mta, they would both > need a fork of virtual/mta. Now one of those forks will be preferred > and used, e.g. the kde one. This means, that you cannot install the > mta from sunrise to satisfy the virtual without additional manual > work.
So far this is only a hypothetical example, as there is no MTA package in the KDE overlay. As long as sunrise is the only overlay providing such a package, I don't see how maintaining a fork of the virtual would be problematic. Any collision scenarios can be solved when they really arise (if ever). > The only way to solve this properly without asking the user to > manually adjust things is to just add all mtas from overlays (maybe > restricted to dev-controlled or -managed overlays) to virtual/mta in > the main tree. The additional entries in the any-of-many dependency are not an issue. But the problem that I see with this approach is that a maintainer of a package depending on the virtual would have to test if his package works with those additional dependencies from overlays. I'd rather not impose such an additional burden upon maintainers of main tree packages. Ulrich
