app-arch/libarchive: revbump to support static linking #2412
Conversation
NP-Hardass
added
assigned
| lzo? ( >=dev-libs/lzo-2[${MULTILIB_USEDEP},static-libs(+)] ) | ||
| nettle? ( dev-libs/nettle:0=[${MULTILIB_USEDEP},static-libs(+)] ) | ||
| zlib? ( sys-libs/zlib[${MULTILIB_USEDEP},static-libs(+)] )" | ||
| RDEPEND="!static? ( ${LIB_DEPEND//\[static-libs(+)]} )" |
There was a problem hiding this comment.
instead of this replacement thing, just do sys-libs/zlib[${MULTILIB_USEDEP},static-libs(+)?] for instance. Many ebuilds in the tree do this. Doing bash replacement for RDEPEND is not nice.
|
If I understand correctly, unlike the current commit,
`sys-libs/zlib[${MULTILIB_USEDEP},static-libs(+)?]`
would force `sys-libs/zlib[static-libs]` also when
`app-arch/libarchive[-static,static-libs]`. But I guess this should not
matter since having libarchive.a without libz.a only makes sense when
mixing static and dynamic linking (which is discouraged).
|
|
Ok, that is indeed a valid point. One way to circumvent the problem is to either require both flags, or none, which excludes the "-static +static-libs" case (which is undesirable for Gentoo in most cases anyways). Hence, |
|
I don't see why "-static +static-libs" is undesirable. People might
want to statically link their own binaries against libarchive while not
caring about the three binaries installed by libarchive.
Anyway, there was something wrong with the regex, but this is now fixed.
I've kept the ugly DEPEND logic to give users the maximum amount of
choice.
|
|
Do you have a very good reason to use static linking there? Static linking is a huge can of worms, and shouldn't be introduced unless there is no other solution. |
|
Static linking was requested in bug 591096, see in particular
https://bugs.gentoo.org/show_bug.cgi?id=591096#c5
|
mgorny
removed
the
assigned
|
Pull Request assignment Areas affected: ebuilds app-arch/libarchive: @gentoo/bsd |
gentoo-repo-qa-bot
added
the
assigned
|
I'm against static linking, and nobody else in the team has merged the PR in 10 months. I think it's quite unlikely for any more progress to be made here, so I'm closing it. We can reopen if anything changes in the future. |
No description provided.