Summary: | mail-client/mail-notification-5.4-r1 duplicated RDEPEND on dev-libs/gmime | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ylosar Goer <gentoo.bugs.10> |
Component: | Current packages | Assignee: | Hans de Graaff <graaff> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | net-mail+disabled |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Created attachment 202409 [details]
emerge --info
And the needed dep is =dev-libs/gmime-2.2* as mail-notification does not work with gmime:2.4 This is intentional. mail-notification needs at least gmime 2.2.7, but it must not be a gmime 2.4.* version. Since there isn't a way to express a single ranged dependency this is solved by adding two complimentary dependencies. Did this cause actual problems for you? > This is intentional. mail-notification needs at least gmime 2.2.7, but it must > not be a gmime 2.4.* version. But '>=gmime-2.2.7' actually brings an unwanted 2.4.3, while the only '=gmime-2.2*' living in the tree is 2.2.23 which is >2.2.7 anyway. > Did this cause actual problems for you? No, not really, except gmime-2.4 gets installed too while ideally it should not as only gmime-2.2 will be used. I just saw in subversion ebuild that one can combine '>=' with slot info, so something like '>=dev-libs/gmime-2.2.7:0' may be the thing here. Ah right, EAPI=1 offers slot dependencies like that. I've now updated to ebuild to use this instead. Thanks! |
mail-notification's ebuild specifies two unconditionnal dependencies on gmime : >=dev-libs/gmime-2.2.7 and =dev-libs/gmime-2.2* >=gmime-2.2.7 resolves to gmime-2.4.3 while =gmime-2.2* resolves to gmime-2.2.23. Those versions are in two different slots so portage wants them both installed. I am not sure whether this is intentionnal or not but it seems weird to me.