tech-pkg archive

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

Re: Failure message when inconsistent X11_TYPE

Hauke Fath <> 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

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

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
>, 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

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index