Bug 503146 – dev-libs/libgcrypt-1.5.3-r100[static-libs] conflicts with dev-libs/libgcrypt-1.6.1-r1[static-libs]

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Maciej Piechotka 2014-03-01 18:27:22 UTC]

* Detected file collision(s):
 * 
 *      /usr/lib64/libgcrypt.a
 *      /usr/lib64/libgcrypt.la
 *      /usr/lib32/libgcrypt.a
 *      /usr/lib32/libgcrypt.la
 * 
 * Searching all installed packages for file collisions...
 * 
 * Press Ctrl-C to Stop
 * 
 * dev-libs/libgcrypt-1.6.1-r1:0::gentoo
 *      /usr/lib32/libgcrypt.a
 *      /usr/lib32/libgcrypt.la
 *      /usr/lib64/libgcrypt.a
 *      /usr/lib64/libgcrypt.la

[Comment 1 Maciej Piechotka 2014-03-01 18:29:02 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.

[Comment 2 Mike Gilbert 2014-03-01 18:36:19 UTC]

I can't think of any reason to enable static libs for binary compatibility. It should probably just be hard-coded to --disable-static.

[Comment 3 Michał Górny 2014-03-01 18:49:27 UTC]

+  01 Mar 2014; Michał Górny <[e-mail]> libgcrypt-1.5.3-r100.ebuild:
+  Disable static libs in the compat slot, bug #503146.

My bad :).

[Comment 4 Maciej Piechotka 2014-03-01 19:03:35 UTC]

(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.

[Comment 5 Michał Górny 2014-03-01 19:05:42 UTC]

Oh yes, we need to change all rev-deps to use slot :0.

[Comment 6 Maciej Piechotka 2014-03-05 20:21:54 UTC]

(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.

[Comment 7 Michał Górny 2014-03-05 21:08:19 UTC]

I don't understand what you're talking about. What is the problem that you're trying to solve now?

[Comment 8 Maciej Piechotka 2014-04-18 19:08:16 UTC]

(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).

[Comment 9 Michał Górny 2014-04-18 20:58:14 UTC]

(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)