I am not sure if I was clear enough on irc, so: >=net-proxy/squid-3.2.1 needs net-libs/libecap-0.2.0 which is currently masked (bug #379343). net-libs/libecap's only rdep in the tree is net-proxy/squid. If you give the go ahead, I can: * slot "0" for <net-libs/libecap-0.2.0 (already done by default) * slot "2" for >=net-libs/libecap-0.2.0 * modify <net-proxy/squid-3.2.1 deps to net-libs/libecap:0 * modify >=net-proxy/squid-3.2.1 deps to net-libs/libecap:2 If you have any other suggestion, please let me know. Currently, squid-3.2.1[caps] will require users to manually unmask net-libs/libecap-0.2.0.
Done as above. Closing.
* Messages for package net-libs/libecap-0.2.0: * This package will overwrite one or more files that may belong to other * packages (see list below). You can use a command such as `portageq * owners / <filename>` to identify the installed package that owns a * file. If portageq reports that only one package owns a file then do * NOT file a bug report. A bug report is only useful if it identifies at * least two or more packages that are known to install the same file(s). * If a collision occurs and you can not explain where the file came from * then you should simply ignore the collision since there is not enough * information to determine if a real problem exists. Please do NOT file * a bug report at http://bugs.gentoo.org unless you report exactly which * two packages install the same file(s). Once again, please do NOT file * a bug report unless you have completely understood the above message. * * Detected file collision(s): * * /usr/include/libecap/common/name.h * /usr/include/libecap/common/body.h * /usr/include/libecap/common/errors.h * /usr/include/libecap/common/autoconf.h * /usr/include/libecap/common/area.h * /usr/include/libecap/common/registry.h * /usr/include/libecap/common/call.h * /usr/include/libecap/common/message.h * /usr/include/libecap/common/delay.h * /usr/include/libecap/common/forward.h * /usr/include/libecap/common/names.h * /usr/include/libecap/common/body_size.h * /usr/include/libecap/common/version.h * /usr/include/libecap/common/log.h * /usr/include/libecap/common/libecap.h * /usr/include/libecap/common/memory.h * /usr/include/libecap/common/header.h * /usr/include/libecap/adapter/xaction.h * /usr/include/libecap/adapter/service.h * /usr/include/libecap/host/xaction.h * /usr/include/libecap/host/host.h * /usr/lib64/libecap.so
Bleh. + 04 Sep 2012; Eray Aslan <eras@gentoo.org> libecap-0.0.2.ebuild, + libecap-0.0.3.ebuild, libecap-0.2.0.ebuild: + Add blockers to different slots - bug #432942 +
This isn't the way to go. SLOTting packages is done to allow multiple versions to be installed at once. Blocking other SLOTs in the very same bunch of ebuilds negates that entirely, so there is no reason at all to do both if you simply don't do one of them. Not just that, the original mask was there because the package installed a library without a SONAME bump, so that packages linking against it would see API incompatibilities. This problem hasn't been addressed at all.
(In reply to comment #4) > This problem hasn't been addressed at all. I am not going to address that. Diverging from upstream in soname bumps is just asking for trouble down the road. If you have any suggestion on how to proceed, please let me know.
(In reply to comment #5) > (In reply to comment #4) > > This problem hasn't been addressed at all. > > I am not going to address that. Diverging from upstream in soname bumps is > just asking for trouble down the road. So mask it again. It was broken when it entered the tree and nothing has happened since except more breakage.
Until this is addressed in squid, that is.
(In reply to comment #6) > So mask it again. It was broken when it entered the tree and nothing has > happened since except more breakage. This is not a pragmatic view. We will be masking libecap-0.2.0 and >=squid-3.2.1 until libecap upstream bumps its soname - good luck with that. What I did is ugly as hell but it lets our users use the software. I guess we will have to agree to disagree. Perhaps we should get some input from other devs/concerned parties and proceeding accordingly? In any case, I do not think masking newer versions of squid is the best outcome but I will follow the general consensus.
Maybe something changed between the time I did the bump/mask and now, but what I see is, squid used to link against libecap.so (instead of something with a SONAME) so upgrading libecap would succeed, revdep-rebuild would find nothing to fix, and yet (re)starting squid would then fail. So just go right ahead and maintain SLOTted ebuilds that mask each other. This is apparently way over my head.
