Bug 257376 - editors/vim: nonsensical dependancies
Summary: editors/vim: nonsensical dependancies
Status: Closed Not A Bug
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Kubilay Kocak
: 257377 (view as bug list)
Depends on:
Reported: 2021-07-24 05:05 UTC by David E. O'Brien
Modified: 2021-07-25 00:43 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (adamw)


Note You need to log in before you can comment on or make changes to this bug.
Description David E. O'Brien freebsd_committer 2021-07-24 05:05:10 UTC
$ pkg install vim
	spidermonkey78: 78.7.0_5
	sqlite3: 3.35.5_3,1
	tiff: 4.3.0
	tpm-emulator: 0.7.4_2
	trousers: 0.3.14_3

Why in the world does an editor need TPM (trust platform module) support?
Much less an emulator giving you a software TPM [vs. the trustable hardware TPM].

Why does an editor require an SQL backend and a web framework (JavaScript interpreter)?
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2021-07-24 05:07:04 UTC
*** Bug 257377 has been marked as a duplicate of this bug. ***
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2021-07-24 05:13:20 UTC
Hi David.

There are several vim ports, for different use cases.

The default (editors/vim), has the following options, and respective defaults:

===> The following configuration options are available for vim-8.2.3081:
     CSCOPE=on: cscope support
     DEFAULT_VIMRC=on: Install bundled vimrc as default setting
     MAKE_JOBS=off: Enable parallel build
     NLS=on: Native Language Support
     XTERM_SAVE=off: Restore xterm screen after exit
====> Optional language bindings
     LUA=off: Lua scripting language support
     PERL=on: Perl scripting language support
     PYTHON=on: Python bindings or support
     RUBY=on: Ruby bindings or support
     SCHEME=off: MzScheme (Racket) bindings
     TCL=off: Tcl scripting language support
====> Options available for the single CTAGS: you have to select exactly one of them
     CTAGS_BASE=off: Use system ctags
     CTAGS_EXUBERANT=on: Use exctags instead of ctags
     CTAGS_UNIVERSAL=off: Use uctags instead of ctags
====> User interface: you have to select exactly one of them
     ATHENA=off: Athena GUI toolkit
     CONSOLE=off: Console/terminal mode
     GTK2=off: GTK+ 2 GUI toolkit support
     GTK3=on: GTK+ 3 GUI toolkit support
     MOTIF=off: Motif widget library support
     X11=off: X11 (graphics) support
===> Use 'make config' to modify these settings

Many of these optional features have their own dependencies.

While this is not a support forum, i'll describe a short summary of options:

Alternative vim ports, with much smaller dependency sets:

  - editors/vim-lite
  - editors/vim-console

If you use ports, disable any or all of the features that aren't desired.

If you find however there are specific 'spurious' (incorrect, inaccurate) dependencies, please re-open this issue with additional details
Comment 3 andrew 2021-07-24 06:59:03 UTC
BTW, the specific answers are:

tpm-emulator and trousers are dependencies of gnutls, which is a dependency of cups, which is a dependency of gtk30;

spidermonkey78 is a dependency of polkit, which is a dependency of colord, which is a dependency of gtk30;

sqlite3 is a dependency of colord, which is a dependency of gtk30.

(If building from ports, turning off gtk30's COLORD option, or colord's POLKIT option will save a noticable amount of effort if spidermonkey is not also being pulled in by something else.)
Comment 4 Adam Weinberger freebsd_committer 2021-07-24 15:31:09 UTC
The decision to make GUI vim the default was made back when you maintained the port. I inherited that decision, and I'm obligated to stick with it. Personally, I think that the vim port should be console-only, and GUIs should be an optional addition package. POLA, though, requires me to stick with the most common GUI toolkit for the default package.

So, yes, GTK3 has an absurd number of dependencies, and of course gvim uses only a small fraction of those. There is, however, nothing I can do about it. GTK3 brings in those dependencies. Personally I build with the X11 option for desktop machines, and console-only installations should absolutely be using the vim-console package instead.
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2021-07-24 23:25:51 UTC
(In reply to Adam Weinberger from comment #4)

I believe there's been sufficient user support requests, user confusion, and support costs paid over the years associated with the current setup that considering ways we could improve the situation would not be rejected out of hand by the community. Things change and POLA is not a universal, particularly if there's quality communication. I would also argue that the current state has an element of POLA to it, given the surprise of many users around how big the vim port is.

Question: Do what extent is it possible to 'sub package' vim, such that ports/packages can be cumulatively installed to add features/modules, rather than each port being mutually exclusive?
Comment 6 Adam Weinberger freebsd_committer 2021-07-25 00:43:28 UTC
(In reply to Kubilay Kocak from comment #5)

With vim, very little. gvim is a soft link to the vim binary, and that binary is linked with the UI toolkit. We could second-guess that and make gvim its own binary, but that will break `vim -g` and is itself a POLA problem.

When I took over the port, there was vim (+gtk2) and vim-lite (TUI only). I changed it to vim, vim-console, and vim-tiny, as that made much more sense to me. I got angry emails for MONTHS about it.

Making the default vim be console-only makes so much more sense to me, but I'm pretty hesitant to change things unless there's a whole lot of buy-in from our user base.

In an ideal world, vim would install console vim, and vim-gtk3 would install a gtk3-linked gvim. We could make vim be console, and vim-gtk3 a separate (and conflicting) package, but I'd predict an equal number of people in a panic over their GUI vim disappearing.

I'm not sure how to resolve it.