On Wed, 3 Jan 2001, Jared D. McNeill wrote:

> On Wed, 3 Jan 2001, Frederick Bruckman wrote:
> > On Tue, 2 Jan 2001, Jared D. McNeill wrote:
> > > Maybe we need something similar to ONLY_FOR_PLATFORM, except for X.
> > > Example, if a package requires XFree86 4.0 or greater:
> > >   ONLY_FOR_X=3D=09XFree86-[4-9].*
> >
> > AFAIK, there's no "uname" for X. IMO, the best thing would be to
>
> X -version gives version information -- that would be easy to parse:
>
>   X -version 2>&1 | grep '^XFree86 Version' | cut -d \  -f 3
>
> Returns '3.3.6' on my system.

Interesting, but I suspect that doesn't work on all ports, and what if
the user drops in a different Xserver, as is commonly done on mac68k?
[The distributed Xmac68k server still doesn't do color.]

> > follow the example of IS_BUILTIN_XPM, and do some kind of feature
> > test, as required. Note that anything in bsd.pkg.mk only helps for
> > building packages from source. It's so when the release switches to
> > XFree86-4.0.x, pkgsrc will be ready. Many binary packages built
> > against 4.0.2 would have missing dependencies or be otherwise broken
> > on stock NetBSD-1.5.
>
> What if, for example, somebody packages DRI for NetBSD? This requires
> XFree86 4.0 or greater. If somebody is building packages against the
> current release (which ships with XFree86 3.3.6), the package will not
> build.

DRI _is_ XFree86-4.x. (It's like the -current version of the Xserver
plus shared libs.) The cvs checkout has no dependencies on installed
X. I can verify that it builds fine on a "stock" 1.5 system. Moreover,
your test only invokes the installed Xserver; it says nothing about
what client libs or includes are installed.

> Wouldn't it be better to give a message saying 'This package
> requires XFree86 4.0 or greater' than to have the package build
> mysteriously die?

Well, sure, but nothing you build is going to depend on what version
of *Xserver* you have installed. XFree 4 mostly changes the server;
only one or two of the old client libs gets a minor version bump.
The major change, for pkgsrc, is the new libraries, and that's pretty
much taken care of by now.

> If somebody decides that they want to build a set of
> binary packages against XFree86 4.0, the DRI package will be present. If
> they're building against 3.3.6, the DRI package won't be built. Pkgsrc
> may be ready for XFree86 4.0, but we're losing out on the features that i=
t
> offers if we require that packages build against both.

If you package some software that only builds on XFree86-4.x, I'm sure
we can find a way to deal with that.

> ONLY_FOR_X would also be useful for the xpm and Mesa packages -- neither
> of these are needed with XFree86 4.0, so why bother building them?

The pkgsrc folks are way ahead of you. If you try to build xpm against
XFree86-4.x now, it gives you a friendly message (and no package).
Ren=E9 Hexel has made Mesa into a meta-package that does the right thing
on XFree86-4 or 3.

--=20

Frederick