Re: xterm and desktop-file-utils dependency

[David Brownlee <abs%absd.org@localhost>]

On Sat, 6 Aug 2022 at 16:06, Greg Troxel <gdt%lexort.com@localhost> wrote:
> [pmc hat firmly off]
>
> David Brownlee <abs%absd.org@localhost> writes:
>
> > On Mon, 18 Jul 2022 at 18:38, Vitaly Shevtsov <shev.vt1984%gmail.com@localhost> wrote:
> >> Can desktop-file-utils be optional for xterm? Because this dependence
> >> requires heavy glib2 and it seems removing it from x11/xterm/Makefile
> >> has no side effects.
>
> One question is how populated your corner of the pkgsrc-using space is.
> While we tree to accomodate most people in many ways, there is often a
> cost to others in complexity.  So I'd like to ask about that.
>
> On my desktop system, glib2 is required by 97 packages.
> On two servers, one has it because of ffmpeg4, and one does not.
>
> So, I wonder if you are using it on a server machine with no local
> display, and you are doing nothing else "desktoppy" (to misuse a
> non-word) on that machine?
>
> Are you building yourself, or using binary packages?  What is the total
> size of all of your packages and how does 16 MB compare?
>
> Or do you have a problem with the presence of glib2, vs "heavy"?
>
> I have problems with a bunch of things from time to time, being bloated
> or nonportable, but by list is more things like rust, nodejs, haskell,
> qt5 and cmake.  glib2 just does not show up in my world as a problem.
> Even on the server that has it, it's tiny compared to the stuff that
> requires it.

Granted, but a change to those would affect the final end state for
users who do need them, the goal for this change was to just defer the
build cost of desktop-file-utils until needed - so it would not affect
the end state for anyone who used it, just those who did not.

> I acknowledge that xterm is small.
>
> > There are probably two obvious approaches to this.
>
> The third is to not do anything :-) I think that always has to be on the
> table.  Of course Vitaly can always just comment out that line.  But
> it's more or less your first option, less easy for users, and less
> cognitive load for everybody.
>
> > The simpler would be to add a desktopdb option to xterm/options.mk
> > (defaulting to on), though all other packages including
> > sysutils/desktop-file-utils/desktopdb.mk should really be updated to
> > match
>
> Agreed, and this is a bunch of code.
>
> > A better approach would probably be to adjust
> > desktop-file-utils/desktop.db.mk to not depend on the
> > desktop-file-utils package, and desktop-file-utils/files/install.tmpl
> > to check for the presence of UPDATE_DESKTOPDB before calling it.
> > desktop-file-utils already calls UPDATE_DESKTOPDB on install, so it
> > should Just Work... I might have a poke at this later :)
>
> It sounds like you think that we can have
>
>   a full dependency on desktop-file-utils for things that use the files
>
>   this limited dependency for things that provide files
>
>   and critically, the property that the system state does not depend on
>   the order of package installation and deinstallation, for any legal
>   ordering
>
>   perhaps, no additional script files installed and having to run as
>   part of package installation and deinstallation compared to where we
>   are now
>

Exactly, currently
- update-desktop-database is run after desktop-file-utils is
installed, and after any desktop.db.mk using package is installed
the proposed change would switch (would have switched) this to
- update-desktop-database is run after desktop-file-utils is
installed, and after any desktop.db.mk using package is installed if
desktop-file-utils is already installed

The effective difference in behaviour is when someone installs one or
more package using desktop.db.mk, and no package which depending on
desktop-file-utils - all the individual files would still be in
share/applications/, but mimeinfo.cache would not be (which in this
context would be the desired behaviour).

The final state where a desktop-file-utils depending package is
installed should be the same as per now (potentially with a few less
update-desktop-database incremental update calls).

update-desktop-database(1) notes:
       The order of the desktop files found for a MIME type is not
       significant.  Therefore, an external mechanism must be used to
       determine what is the preferred desktop file for a MIME type.
so it really shouldn't matter if its run after a bunch of files are
added to share/applications, or after each one, as long as its run at
the end of a set of packages being installed.

I'm a nominally disinterested party here - this was prompted by a
comment on pkgsrc-users@, and it seemed like a reasonable question.

> Overall I don't think glib2 is big, and that the case of
>
>   a system with no glib2
>   a system with no desktop-file-utils
>   wanting xterm
>   being bothered by glib2
>
> is extremely rare, perhaps only 1 human.  So I'm very reluctant for us
> to add complexity for it.

That's also a reasonable approach - I'd note that the binary package
of glib2 install also pulls in pcre & libffi on NetBSD, and
potentially libiconv, gettext, and zlib - (none of which are massive
and are all also used elsewhere), but resultant build pulls in meson,
python and all of their dependencies, so for a user trying to build a
couple of small packages could easily end up building orders of
magnitude more for "desktop-file-utils" than the package itself, which
is not a good experience on on a less than massively performant box.
Even if they may want to build something using glib2 later, avoiding
the unnecessary cost up-front for a small package is a win. Actually I
would have probably benefited from this a couple of times in the past
when building packages and waiting for a smaller, more urgent one to
complete, so maybe I'm not disinterested :-O

In short - the change is small, relatively safe, should not result in
any difference in final state for the general case where someone
installs a package which uses share/applications/mimeinfo.cache, and
could significantly benefit some people building a small set of
packages on smaller & less mainstream boxes, and _very_ slightly
benefit a small number using binary packages.

Against which, it is a tiny bit of complexity, and does not benefit or
affect the majority of users.

I think that's a fair summary from my perspective :)

I'm obviously in favour, though I agree there are valid arguments to
decide either way, I just wanted to opportunity to summarise what I
believed them to be :-p

David