Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Jan 2004 11:32:46 -0800
From:      Eric Anholt <anholt@FreeBSD.org>
To:        Alexander Leidinger <Alexander@Leidinger.net>
Cc:        ports-committers@FreeBSD.org
Subject:   Re: cvs commit: ports/x11 Makefile ports/x11/libXpm Makefile distinfo         pkg-descr pkg-plist
Message-ID:  <1075059166.703.37.camel@leguin>
In-Reply-To: <20040125125547.56311882@Magellan.Leidinger.net>
References:  <200401251014.i0PAE8G2004435@repoman.freebsd.org> <20040125125547.56311882@Magellan.Leidinger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2004-01-25 at 03:55, Alexander Leidinger wrote:
> On Sun, 25 Jan 2004 02:14:08 -0800 (PST)
> Eric Anholt <anholt@FreeBSD.org> wrote:
> 
> >   Testing is encouraged, but please do not use these ports as dependencies until
> >   the XFree86 ports have been updated to depend on them.
> 
> Do you really intend to let XFree86 depend on it? I haven't followed
> what happened that much, but I have the impression you are committing
> ports for the XFree86 fork (Xouvert?), and as such it would be a little
> bit odd to let XFree86 depend on it.
> 
> If I got the details right and if there will be a "Xfork"-port: will it
> be available as an option for the XFREE86_VERSION variable?

Yes, I really intend to replace XFree86's libraries with freedesktop.org
libraries where there's an fd.o version available.  There's a reason
that every XFree86 maintainer I've talked to (OK, just RedHat, Debian,
Gentoo, and someone from NetBSD) is excited about this.  XFree86 is
terrible to maintain.  Look at the files/ in XFree86-4-libraries and
-Server.  And we aren't doing nearly as much as we should with these
ports to make them good ports citizens, let alone stay up to date with
important changes in XFree86.

The benefits will be many when we're finished.  When there's a security
issue in libXfont (or libXau or libXdmcp), you'll only have to update
libXfont instead of all the X Servers that link it in statically because
of XFree86's build.  Updates to single ports will be faster in testing
and for end users because you can just build the library, instead of
building all of the XFree86-4-libraries and committing, hoping that
having that patch in files/ doesn't break XFree86-4-whateverelse.  Plus,
there'll be a much faster release cycle than XFree86's yearly release.

This is not a fork of XFree86.  Notably, we (as in fd.o) don't have any
fork of the XFree86 X Server*.  This is just the libraries.  There is an
X Server at freedesktop.org, which shares the internal X Server parts
but has different DDXs, along with the new extensions (fixes, damage,
and composite).  I've been working off and on on porting that server,
but I don't think I'll be able to finish it before I leave.  Xouvert is
a dead project (if you can say it was ever alive to begin with) that no
established X hackers worked on.

* This actually may change.  There's been talk, and one person hacking
on, importing the XFree86 DDX into the X Server tree and fixing it to
work with Composite.  I have serious doubts myself about the viability
of trying to do minor fixes to XAA instead of axing it and starting from
scratch, given its major limitations in the presence of Composite and
increased use of Render, which is why I've been spending so much time on
the kdrive server.

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1075059166.703.37.camel>