Control: tags 891931 + wontfix Hi xnox--
Thanks for reporting this concern. I don't agree with the strategy you propose below, but i appreciate the opportunity to explain my reasoning. I'm marking it "wontfix" so that my intent on packaging is clear, but I'm fine with continued discussion on it if you like. On Fri 2018-03-02 17:59:53 +0000, Dimitri John Ledkov wrote: > Above resulted, in many guides and low-level tools forcing and > hardcoding installation of the `bin:gnupg' package. For example, > live-build / deboostrapping tools still hard code installing > `bin:gnupg' package, enough though `bin:gpgv' is sufficient for > secure-apt. agreed. this is a bug in those tools, and we should encourage them to switch to gpgv. > Some of the `bin:gnupg' users are running very minimal systems, and do > need key management. Thus these systems upon upgrade, would exect to > stay minimal, and thus "upgrade" to the `bin:gpg' package. yes, those packages that need minimal configuraton should stay with "bin:gpg". > This is unacceptable. We are in the process of fixing and dropping the > usage of `bin:gnupg' or replacing it with more granular packages as > appropriate. Great, thanks! Having the capacity for that granularity was exactly the point of this upgrade. > However, I believe it is confusing to have two package names with very > similar names (gnupg & gpg), and I believe very little people are > aware of the fact that interactive/desktop systems probably want > `bin:gnupg' whilst all automation scripts need updating from gnupg -> > gpg package names, conditional on existance of gpg. I don't think i agree with the global assessment that interactive/desktop systems want the full suite and automation/scripts want the piecemeal/granular installation. There are certainly counterexamples (e.g. trimmed-down, dedicated purpose interactive desktop systems, or scripted servers that do more sophisticated things with GnuPG, like secret key management, network access, etc). > And imho, it is an upgrade regression to change the meaning of > `bin:gnupg` from `provides /usr/bin/gpg` to `high-level collection of > local and networking cryptography tools`. Thanks for reporting this. I hear your frustration but i think the meaning of the gnupg package has traditionally meant "able to use GnuPG in all contexts". As upstream GnuPG has become more modular, simply installing /usr/bin/gpg will *not work* in scenarios where (for example): * the user needs to handle secret keys (this needs gpg-agent) * the user needs to interact with the network (this needs dirmngr) GnuPG upstream also builds a range of tools for other functionality, and the suite as a whole is known as "GnuPG". If we want the guidance littered around the web to keep working, then we need to continue to supply the full functionality. > Thus please consider making `bin:gnupg' what `bin:gpg' package > currently is - a minimal provider of /usr/bin/gpg only, for the sake > of keeping upgrades small. Drop `bin:gpg' package name. And please > consider make the new package name to be the meta of all the things, > e.g. `bin:gnupg-all', `bin:gnupg-meta' or some such. sorry, but i am not convinced that this change is the right thing. The "GnuPG" name refers to the GnuPG project. "gpg" refers to the binary on its own. One additional approach would be to have "gpg" refer to just the binary, "gnupg" refer to "gpg" plus the traditional "gpg-agent" and "dirmngr", and then some complete "gnupg-all" wihch depends on everything produced by the GnuPG upstream code, but that makes the dependency graph even worse, and adds one more package. I've gotten enough pushback on the number of packages that i'm not inclined to add any more, and i don't think the extra complexity that would entail would be worthwhile. I'm tempted, frankly, to collapse the package suite still further, reducing the number of packages in total, but potentially increasing the number of external dependencies. See the "GnuPG package split and interlocking dependencies" thread on pkg-gnupg-maint last September, in particular: http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-September/006023.html Making the packaging interdependencies even more complex does not seem like a good thing. > I understand that this may result in regressions, e.g. if existing > users of `bin:gnupg' are expecting the full-interactive > suite. However, interactive users are easier to fix their systems, > than automated/scripted/cross-distro-version deploys. To prevent > interactive systems regressing, please consider adding `Recommends: > gnupg-all` (or maybe Suggests) to the new minimal `bin:gnupg' package. I think this argument works the other way around. Having a server by default upgrade to the more minimal dependency leaves you in the direction of missing functionality on systems that are harder to repair. Therefore, it makes more sense to install the full package on upgrades for systems that used to use the full GnuPG functionality, and allow those who prefer to prune to prune on their own (as you've described is already happening above). Let me know if you have any other ideas that might help to illuminate the problem space further. As it stands, i think: * you have the ability to declare a dependency on just the parts you want (it's fine-grained, so narrowly-scoped tools should be able to pick what they want * the interdependencies between packages is probably a bit too complex, but isn't unmanagable yet * upgrades are likely to err on the side of a more complete installation, but can be pruned back afterward, if their administrators want. This isn't a great situation, but it's not a particularly bad equilibrium point between the various tradeoffs. Regards, --dkg
signature.asc
Description: PGP signature