Re: Failure message when inconsistent X11_TYPE

[Hauke Fath <hf%spg.tu-darmstadt.de@localhost>]

On 7/21/21 2:44 PM, Greg Troxel wrote:
> Frederic Fauberteau <triaxx%NetBSD.org@localhost> writes:
> > mkfontdir has been added by FONTS_DIRS.x11 as reminded by Joerg. When
> > I look at the PLIST file, I understand that this tool generates fonts
> > in the 3 directories listed in FONTS_DIRS.x11. Then it is needed to
> > build the package and must be provided by either a xbase set or by
> > pkgsrc.
> >
> > [...]
>
> So, it seems clear that the xemacs-packages actually does depend on x11,
> and the new code has correctly flagged a situation where X11_TYPE is
> native but the tools are missing, which I expect leads to a situation
> where the binary package is different than in the standard approach.
>
> It would be interesting to look at the build log and see what happens
> when mkfontdir is attempted to be invoked.  Really that failure should
> fail the build.

Nothing much:

=> Becoming ``root'' to make su-real-package-install (/usr/pkg/bin/sudo)
===> Installing binary package of xemacs-packages-1.18nb6
xemacs-packages-1.18nb6: updating font database in 
/usr/pkg/lib/xemacs/xemacs-packages/etc/x-symbol/fonts (x11)
xemacs-packages-1.18nb6: updating font database in 
/usr/pkg/lib/xemacs/xemacs-packages/etc/x-symbol/origfonts (x11)
xemacs-packages-1.18nb6: updating font database in 
/usr/pkg/lib/xemacs/xemacs-packages/etc/x-symbol/pcf (x11)
=> Dropping ``root'' privileges.

> One could also build xemacs-packages on a system with X11_TYPE=modular
> but no installed packages and see what gets pulled in.

Font things:

[hf@Unspitze] /<2>editors/xemacs-packages > make CLEANDEPENDS=yes clean
===> Cleaning for cwrappers-20180325
===> Cleaning for digest-20190127
===> Cleaning for checkperms-1.12
===> Cleaning for gtar-base-1.34
===> Cleaning for m4-1.4.19
===> Cleaning for libtool-base-2.4.6nb3
===> Cleaning for readline-8.1
===> Cleaning for gdbm-1.20
===> Cleaning for perl-5.34.0nb2
===> Cleaning for gmake-4.3nb2
===> Cleaning for pkgconf-1.7.4nb1
===> Cleaning for libffi-3.3nb5
===> Cleaning for gettext-lib-0.21
===> Cleaning for gettext-tools-0.21nb3
===> Cleaning for bison-3.7.6nb1
===> Cleaning for re2c-2.1.1
===> Cleaning for libuuid-2.32.1
===> Cleaning for python38-3.8.11
===> Cleaning for ninja-build-1.10.2
===> Cleaning for py38-expat-3.8.11
===> Cleaning for py38-setuptools-57.2.0
===> Cleaning for meson-0.58.1
===> Cleaning for pcre-8.45
===> Cleaning for glib2-2.68.3nb1
===> Cleaning for glib2-tools-2.68.3
===> Cleaning for desktop-file-utils-0.26
===> Cleaning for xemacs-21.4.24nb17
===> Cleaning for xorgproto-2021.4
===> Cleaning for libfontenc-1.1.4
===> Cleaning for freetype2-2.10.4
===> Cleaning for mkfontscale-1.2.1
===> Cleaning for encodings-1.0.5
===> Cleaning for p5-gettext-1.07nb6
===> Cleaning for help2man-1.48.3nb1
===> Cleaning for autoconf-2.71nb1
===> Cleaning for gmp-6.2.1
===> Cleaning for mpfr-4.1.0
===> Cleaning for gawk-5.1.0
===> Cleaning for xemacs-packages-1.18nb6
[hf@Unspitze] /<2>editors/xemacs-packages >

> So far, pkgsrc doesn't have X11_TYPE=none.  I suppose that would mean
> that any attempt to depend on X11 (tools or libs) would throw an error.

Given the special role of X11, I think this option should exist.

> That's currently semi-handled by setting modular and not building things
> that use X.  We also don't have any notion of QT5_TYPE=none or
> GTK_TYPE=none to fail building.  So I'd say that if you don't install
> the X11 sets in NetBSD, you should set X11_TYPE to modular, and if you
> haven't done that your system is misconfigured.

While technically correct, with X11_TYPE=modular any random poorly 
configured package can result in pulling in hundreds of little X11 
packages, unless you babysit the build/installation, and play whack-a-mole.

> I use emacsNN-nox11 which avoids an X11 dependency.  (While my system has
> X, I consider emacs to be critical and prefer a leaner build.)    There
> is, amusingly enough even though it is sensible, xemacs-nox11.

Since XEmacs has always supported console operation, this makes sense.

> So xemacs-packages should perhaps grow an x11 option and omit the fonts
> entirely if it is turned on, or be split into xemacs-packages and
> xemacs-packages-x11.

That is what I'll have to decide, yes.

I think cases like this call for soft dependencies: Use FEATURE if 
available, move on if not.

If a package wants to register fonts on a system that does not support 
them, then there is nothing to be done. But failing the build is an 
overreaction - since XEmacs can be run from the console, the x-symbol 
package has to be able to cope anyway.

> As an aside not logically related to the x11 issues, the xemacs DESCRs
> don't say:
>
>    xemacs is a fork of GNU emacs

Just like NetBSD is a fork of 386BSD, yes. Both originated ~30 years ago.

>    they imply that a lot of GNU emacs features touted are special xemacs
>    features

Yes. When they forked, GNU Emacs did not have any graphics support, for 
one. It caught up, eventually.

>    xemacs is no longer maintained upstream (the current stable release
>    has a distfile date of March 2015)

There is an upstream, which is slowly chipping away (hard to find, I'll 
grant you):

<https://foss.heptapod.net/xemacs/xemacs/-/commits/branch/default/>

Bitbucketing the Mercurial repos didn't help, nor did the implosion of 
tux.org, the project's hoster, a few years ago. I don't know about 
imminent release plans. Maybe I should add an xemacs-hg package.

Cheerio,
Hauke

--
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email	        Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-21344