Summary: | mail-filter/opendkim-2.7.1: collides with dev-libs/libstrl | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | Net-Mail Packages <net-mail+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | binki, esigra |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://tinderboxlogs.s3.amazonaws.com/tbamd64.excelsior.flameeyes.eu/dev-libs%3Alibstrl-0.5.1%3A20130118-085658.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 251464 |
Description
Diego Elio Pettenò (RETIRED)
2012-11-04 22:52:42 UTC
(In reply to comment #0) > Not sure to count it as bundling as well, but I'll say so for now... They are the same. But opendkim-2.7.1 fails its tests when linked against dev-libs/libstrl. @Nathan: Any proposals on how to proceed? Fixed in mail-filter/opendkim-2.7.2 with a proper configure check. @Nathan: You should probably check why opendkim tests fail with libstrl. Uhm, no. You now added an automagic dep, and you didn't solve the collision if libstrl is installed _after_ opendkim. Just make it a mandatory dep anyway. Should be fixed now. Went with a mandatory dev-libs/libbsd DEPEND (which inhibits libstrl.so from opendkim) and passes make check. +*opendkim-2.7.4 (18 Jan 2013) + + 18 Jan 2013; Eray Aslan <eras@gentoo.org> + +files/opendkim-2.7.4-DisableCryptoInit.patch, + +files/opendkim-2.7.4-bsd.patch, +files/opendkim.init.r3, + +opendkim-2.7.4.ebuild: + Version bump - bug #452324. Start before mta - bug #451114. Use libbsd instead + of internal library - bug #441790. Add option to disable crypto + initialization thanks to Christian Rößner - bug #452470. + (In reply to comment #2) > Fixed in mail-filter/opendkim-2.7.2 with a proper configure check. > > @Nathan: You should probably check why opendkim tests fail with libstrl. It’s not bundling. The opendkim project decided they wanted to install a public library called “strl” with its own strl.pc, and through a package that would only be installed on mailservers; that methodology does not lend itself to encouraging people to rally around a single implementation of strlcpy()/strlcat() because users would have to install a milter they don’t need just to get opendkim’s “strl” library. Their git code looks like it is broken, as Diego said, because opendkim will _not_ reinstall a copy of its own strl library if a previous installation of opendkim has installed strl. The libbsd solution looks good. Since libbsd exists, maybe libstrl should die. Making dev-libs/libstrl a mandatory dependency would also work (and wouldn’t require the in-tree libbsd-support patch) until opendkim upstream decides to go ahead and use libbsd. Sorry for the untimeliness of my comments :-/. |