| Summary: | portage-2.2_rc35 breaks package.provided | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Andrew Church <achurch+gentoo> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
It's the code from bug #82488 that's doing it. If you create my-mta-1.ebuild and define PROVIDE="virtual/mta" then it will work. Thanks, that fixed the problem. After removing the package.provided entry and merging mail-mta/my-mta, portage-2.2_rc35 no longer attempts to merge mail-mta/ssmtp. |
One of the changes made in portage-2.2_rc35 breaks /etc/portage/profile/package.provided (at least as I understand its use). I have the following in /etc/portage: /etc/portage/profile/package.provided: mail-mta/my-mta # Dummy package name for custom MTA, not in portage /etc/portage/profile/virtuals: virtual/mta mail-mta/my-mta Through portage-2.2_rc33 this setup has worked fine; however, portage-2.2_rc35 attempts to install mail-mta/ssmtp, which (naturally) fails due to a collision on /usr/sbin/sendmail. I suspect the patch from bug 275796 (prefer packages in the graph over installed packages) is at fault, though I wasn't able to reverse it cleanly so I can't be sure. Is this a problem with Portage, or am I misusing package.provided?