Hauke Fath <hf%spg.tu-darmstadt.de@localhost> writes: >> 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. So it should have invoked mkfontdir or something and it wasn't there and it didn't fail. That's a bug (but not sure where). >> 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. I don't think it's that special, so I won't propose an option. You're of course free to bring up a coherent proposal with rationale on tech-pkg. >> 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. That's true of many other packages pulling in many other things that some other people don't like. Some of which are bugs if there's a global option to disable, and some are just hatred :-) > I think cases like this call for soft dependencies: Use FEATURE if > available, move on if not. That is completely contrary to the pkgsrc way, which is that when you build a package, what you get should be controlled by options, and not adapt to the environment, so that you get repeatable builds. Basically, if an optional feature is configured on, hard-depend on things needed to make it work, and > 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. > >> 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/> I didn't find that from HOMEPAGE in the package. But it is not maintained, even if people hope to, because there is no recent formal release. > 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. Sure, many struggles for many reasons. I wasn't trying to say they are bad people, just that in DESCR we try to note when packages are unmaintained for a long time. you might want to drop xemacs-current, too, which is from August of 2013.
Attachment:
signature.asc
Description: PGP signature