tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Failure message when inconsistent X11_TYPE

On 7/21/21 2:44 PM, Greg Troxel wrote:

Frederic Fauberteau <> 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


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

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

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):


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


     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

Home | Main Index | Thread Index | Old Index