On Sun, Oct 21, 2018 at 12:13:27PM -0400, Marvin Renich wrote: > * Sune Vuorela <nos...@vuorela.dk> [181021 06:05]: > > On 2018-10-21, Jonas Smedegaard <jo...@jones.dk> wrote: > > > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all: > > > As a library it cannot possibly declare how tight a relationship to > > > declare - instead, all _consumers_ of the library must declare whether > > > they depend/recommend/suggest gnupg. > > > > libgpgme is completely useless without gnupg. I think it is perfectly > > fine for these kind of relations, unless we really are in corner-case > > territory. See for example fam. > > I strongly agree with Jonas. Upstream links to libgpgme as a .so to > provide optional behavior. This requires libgpgme to be installed in > order to even run neomutt, whether the user wants the feature or not. > It is perfectly reasonable to want to install neomutt but want to _not_ > install gnupg.
Not in Debian. The Debian philosophy in this has always been to link against all libraries where possible, and to detect at runtime whether something can be used. This introduces a much larger dependency tree, but ends up being easier to use for most users. The alternative is something like Gentoo, where you *can* decide what you compile in and what you don't. The trouble with Gentoo, however, is that you spend seven hours installing it, and then your mouse doesn't work because you set one USE flag incorrectly and now you have to recompile the universe (I exaggerate, but you get the point). > The proper fix is to convince upstream to dynamically link at runtime > and disable some features if libgpgme is not available. That's a great way to introduce a large set of bugs of the "oops, tried to use libX when dlopen failed for some reason" type. It's better to avoid that issue by just having a hard dependency on the library in question. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
