tech-pkg archive

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

Re: some x11 stuff in pkgsrc is hopelessly broken for slightly older systems



At Thu, 21 Jul 2016 07:05:06 -0400, Greg Troxel <gdt%ir.bbn.com@localhost> wrote:
Subject: Re: some x11 stuff in pkgsrc is hopelessly broken for slightly older systems
> 
> "Greg A. Woods" <woods%planix.ca@localhost> writes:
> 
> > At Thu, 21 Jul 2016 00:16:38 +0200, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> >> Limited support in both cases. For NetBSD 5, we have been advising to
> >> use X11_TYPE=modular for a long time for example. 
> >
> > Sorry I've never seen such a recommendation, and I can't find one in the
> > main pkgsrc document, and I'm not using NetBSD-5 for this situation either.
> > (My old machines are actually still stuck on a much older pkgsrc, sigh.)
> 
> See mk/platform/NetBSD.mk.  On netbsd-5, the use of X11_TYPE=modular is
> the default.

I'm not sure what you're trying to tell me here.

As I said, I know that.  I've read the source.  I've done tests to prove
my understanding is correct.

I am not using NetBSD-5.  (at least not with pkgsrc-current)


> > The actual pkgsrc documentation, as of today, last revision on
> > 2016/07/14, still says that only on DragonFlyBSD is "X11_TYPE=modular"
> > the default.
> 
> Feel free to submit documentation fixes.

Sigh.  Documentation should always be the first thing updated _before_
any change is committed.

If/when someone asks me to review a change and help with the
documentation _before_ it is ever committed, I'll do my best.

I didn't write any of the changes that have caused problems for me, I
have no idea what guided those changes, what the goals where/are, and I
have no idea what the policy is for defaults and best results.  So, I
have no idea what the documentation _should_ say.

Like many others I rely on the documentation to help set my
expectations.  Usually it's only when things go wrong that I use the
source to verify my expectations.  When reading the source dashes my
expectations I blame the documentation, but I also end up in a situation
where I don't know whether to fix the source or the documentation,
especially if I have any thoughts of pushing those fixes upstream.
Unfortunately the state of mind of the developer who made the changes,
and/or updated the documentation, is not recorded anywhere I can access
in the universe so that I can try to use it to figure out which is more
correct.  I can only choose what works best for me, if indeed I can get
anything to work.

I wouldn't have started this thread if the documentation had said
something useful to guide me to avoiding these problems and to set my
expectations such that they wouldn't be dashed on the stones of reality.
I double-checked everything I could find while writing my first message.

> I think we are blurring multiple things.  You are saying "XFree86", but
> the native X11 in modern NetBSD is not XFree86, but an import of xorg,
> which is hence modular.  So the two things to compare are
> 
>   native: the bits in /usr/X11R7
> 
>   Modular: misnamed, but refers to building xorg from pkgsrc

Let me try to be more clear.

I always build from source.  I am a user of NetBSD source code.  I do
not use binaries built by anyone else on my NetBSD-based systems.

In the "xsrc" module in CVS there has been an "xfree" tree since forever
and up until 2015/07/23, and the.same goes for support in
src/share/mk/bsd.x11.mk and src/x11.  This is true in the netbsd-7
branch as well (and in netbsd-6 too of course).

BTW, there is still a junk xsrc/Makefile in -current that should be
replaced by a helpful README file.

In any case the build system has, in my opinion and my experience, fully
supported the use of the xsrc/xfree tree up until now in netbsd-7, and
until now all release branches before it (and until 2015/07/23 in
-current).

Now use of xsrc/xfree (i.e. via building it in src/x11) creates the
normal xbase.tgz, xcomp.tgz, and so on installation sets and, use of
those results in a system that pkgsrc defaults to X11_TYPE=native.

I have showed that pkgsrc detects my xsrc/xfree NetBSD X11 install as
"native".  I've read the source.  I can see that it can only do exactly
what I observe it to do.

I.e. NetBSD-6 and NetBSD-7, and NetBSD-current until 2015/07/23, when
built from source, support XFree86 as the base system X11.  It works,
very well.  At least all the clients and libraries do.  (I've built,
installed, and used it many times on a variety of machines from
Raspberry-Pi to my big Dell servers.  Since the NetBSD-5 release I've
only tested and used the xsrc/xfree Xserver on the Dell servers.)

So, I have what is for all intents and purposes a source-built NetBSD-7
system with an official source-built x11 install that pkgsrc identifies
as X11_TYPE=native, but which is no longer able to build some basic and
widely required pkgsrc/x11 packages (due of course do upstream changes
in those packages which were not accounted for by pkgsrc).

Clearly the statement "native: the bits in /usr/X11R7" is not correct,
or at least not complete, even just for NetBSD, neither is the statement
"the native X11 in modern NetBSD is not XFree86" since it can be.

Perhaps what I am describing does not agree with the *assumptions* that
pkgsrc maintainers have been making since NetBSD-5 about what
constitutes a "native" X11 install on a NetBSD system, but of course
none of these *assumptions* are documented.  Perhaps the pkgsrc
maintainers do not consider NetBSD built from source as fully supported.
I would not know, but from the growing evidence it would seem that they
only consider official NetBSD binary builds to be fully supported -- at
least that is the effect of the way the code for pkgsrc is written and
it is the only way to guarantee that "native == Xorg".

Clearly though there was some awareness of this issue during the time of
NetBSD-5 maintenance, thus the hack of forcing X11_TYPE=modular for
NetBSD-5 alone.

> I know you know this, bu keep in mind that there is much software out
> there and a lot of it is not entirely right.  So in general not
> everything works, and it needs to be fixed.

Yes, of course, but apparently these problems have languished for over a
year now, and have been in the making since NetBSD-6 was first released.


> In /usr/X11R7/lib/pkgconfig (netbsd-7), there are 121 files.  So
> generally the in-tree X has pkgconfig support.

Not if it was built using X11FLAVOUR=XFree86 it doesn't!

> netbsd-6 is less clear.  I am using X11_TYPE=modular on netbsd-6, but
> that's because I used it on netsbd-5 before upgrading, not because
> native didn't work for me.

I haven't got a NetBSD-6, nor an actual netbsd-7 based machine, nor the
resources to build one at this time, but having read all the sources I
cannot imagine that either would ever work with X11FLAVOUR != Xorg.

Anyway, I think the problem is that the term "native" for base-OS X11 is
over-loaded because of the history of the NetBSD "xsrc" CVS module.  Or
at least it has been since (and obviously including) NetBSD-5, and
certainly since X.org upstream packages have started to rely ever-more
on the _current_ state of other X.org packages.

Trying to detect the difference between a workable native X11 and an
unworkable one, especially for non-NetBSD systems, may be possible.
(perhaps by relying on the presence or lack of an "x11.pc" file?  but
what about when making binary packages for other systems?)

If that doesn't work though then perhaps the best solution for the
immediate term might be to force X11_TYPE=modular for _all_ NetBSD
releases and to warn loudly if the user has tried to set it otherwise.
It won't break any builds that are not already ultimately broken --
it'll just reveal the breakage in a different, and hopefully better
(i.e. fixable) way.

Forcing "modular" would annoy some people with extra builds and/or extra
storage requirements though, and potentially hide latent bugs in
differences between base-OS and pkgsrc components, so ideally the
solution is to correctly and automatically detect the default setting of
X11_TYPE for all systems, and especially NetBSD-6 and NetBSD-7 systems,
and to warn or abort when the user tries to provide a different setting,
and to document the choices which will provide the best results.  That
will allow people who want to avoid X11_TYPE=modular to re-install
appropriate base-OS X11 sets if indeed they are available.

Since a future netbsd-8 source branch clearly won't support xsrc/xfree,
the schizophrenia of pkgsrc's X11_TYPE=native will eventually go away,
but in the mean time there are supported branches where it exists and in
my opinion pkgsrc needs to deal with it in some way that helps users
trust pkgsrc and to achieve the best possible results.

-- 
						Greg A. Woods
						Planix, Inc.

<woods%planix.com@localhost>       +1 250 762-7675        http://www.planix.com/

Attachment: pgpvZLd2CSgmP.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index