On 2026/04/17 06:14, Theo Buehler wrote:
> On Thu, Apr 16, 2026 at 09:47:54PM -0500, Brent Cook wrote:
> > 
> > Also, I was puzzled why installing btop pulls in a lot of desktop
> > related dependencies. They were just used to update the icon database
> > on install, but I don't even have a GUI on most machines, and the
> > binary itself is text only I believe. I wonder if we could live
> > without that and make the number of dependencies for this package a
> > lot leaner.
> 
> The initial relatively rough submission tried to do that, but when the
> port was beaten into committable shape this was discarded at some point.
> Just removing the dep isn't ok though because the tag will likely be
> added back in the next update, resulting in a broken or at least a noisy
> package install due to the missing run dependency (haven't tried).

There's a bit of a weakness in the tag mechanism; for desktop and icon
files, we don't actually need to regenerate caches/databases all the
time, just when certain software (mostly DEs) is installed. But @tags
need
to be defined somewhere and for these it's in the gtk-update-icon-cache
/ update-desktop-database packages providing the binary used for these
to
run (which pull in glib2 etc).

This is only really noticeable in a few places i.e. terminal-based
software, that provides icon/desktop menu entries making it easier to
discover and use from desktop environments, when installed on machines
that don't run any gui software (otherwise you have the deps installed
already).

With package tools as they stand (there's no "@tag-optional" or
similar), the choices are

- add the dep/files and @tag. extra deps on text-console-only machines.
- don't add the dep, remove the files. worse experience for DE users.
- add the files but no dep or @tag. cache/db updates generally still do
happen because other packages run the tags (they are run once at the end
of pkg_add run) but 'make plist' will try to put the tags back.

In the cases where the extra deps are annoying (mostly editors, for me)
I tend to go with the latter option and take care with PLIST updates. It
might occasionally miss changes to desktop/icon files if the relevant
package is updated and no others with the @tag are updated (i.e. nothing
to piggyback on) but desktop/icon files don't tend to change in this
sort of software anyway.