Summary: | dev-libs/libgcrypt-1.5.3-r100[static-libs] conflicts with dev-libs/libgcrypt-1.6.1-r1[static-libs] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Maciej Piechotka <uzytkownik2> |
Component: | [OLD] Unspecified | Assignee: | Multilib team <multilib+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | crypto+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Maciej Piechotka
2014-03-01 18:27:22 UTC
I forgot to add - I know that by unmasking packages I accepted responsibility for any problems/breakage so please treat it as information not a complain. I can't think of any reason to enable static libs for binary compatibility. It should probably just be hard-coded to --disable-static. + 01 Mar 2014; Michał Górny <mgorny@gentoo.org> libgcrypt-1.5.3-r100.ebuild: + Disable static libs in the compat slot, bug #503146. My bad :). (In reply to Mike Gilbert from comment #2) > I can't think of any reason to enable static libs for binary compatibility. > It should probably just be hard-coded to --disable-static. It's used by sys-power/suspend[crypt]. Right now it's required by sys-power/suspend-1.0[crypt] requires 1.5.3-r100 (it does not compile ATM as headers are provided by -1.6.1-r1). In general things that go to initramfs are built with static-libs so it might not be a best long-term solution. Oh yes, we need to change all rev-deps to use slot :0. (In reply to Michał Górny from comment #5) > Oh yes, we need to change all rev-deps to use slot :0. Well. It creates problems with >=emul-linux-x86-baselibs/emul-linux-x86-baselibs-20131008-r20 as it requires 1.6 to be in that slot. I wonder if the headers could be installed to different directory just for those few packages. I don't understand what you're talking about. What is the problem that you're trying to solve now? (In reply to Michał Górny from comment #7) > I don't understand what you're talking about. What is the problem that > you're trying to solve now? Sorry for delay. Right now I have packages which forces the 1.5 version in slot 0 (suspend) and which forces 1.6 version (app-emulation/emul-linux-x86-baselibs - now it's masked but in future it might be unmasked). (In reply to Maciej Piechotka from comment #8) > (In reply to Michał Górny from comment #7) > > I don't understand what you're talking about. What is the problem that > > you're trying to solve now? > > Sorry for delay. Right now I have packages which forces the 1.5 version in > slot 0 (suspend) and which forces 1.6 version > (app-emulation/emul-linux-x86-baselibs - now it's masked but in future it > might be unmasked). Then the package needs to depend on: || ( libgcrypt:11 libgcrypt:0/11 ) (or maybe in reverse order, I'm not sure) |