Call Monday 24 Jan 2005
Roland Mainz
roland.mainz@nrubsig.org
Tue Jan 25 15:16:56 PST 2005
Adam Jackson wrote:
> > > Huzzah, the real issue identified. Can we please make this plan _exist_?
> > > I'm tired of sitting in this netherworld where m12n is perpetually put
> > > off by doomsaying.
> >
> > Well, I hope the Xorg conference in february will bring some light into
> > the issue... :)
>
> I don't see why we should wait until February to discuss something that's an
> issue now.
It's faster to do the overall planning on the conference. It's much
quicker than doing it on a mailinglist (and it will likely be less
stressing, too :)
> > > As noted elsewhere, nothing is destroyed by this change.
> >
> > ... just the default build config is horked right now.
>
> So if you're the maintainer for xrx, go turn it back on; and then justify
> including it in a monolith when it's a browser plugin, without resorting to
> arguments of the form "but it was in pre-6.7 releases".
Parts of the xrx technology (like lbx, appgroup, security, Xaw8 etc.)
live in other parts of the monolithic tree. And as Keith Packard said:
There is no other place to put it, the Xorg monolithic tree is the
primary source of this code (excluding the CERN labs version of the
plugin (which is now more or less obsolete as the Xorg foundation now
ships with a working plugin enabled again)). And just splitting off the
source costs time which I don't have right now. Rememeber I only took
maintainership of the xrx stuff as there were several requests to get it
fixed and noone else cared so I did the job after syncing with Egbert.
> You'll have a much harder time convincing me of the continuing value of old
> rotting source packages (extras/). And please don't make the "but the distro
> might have an old version" argument; that's the distro's bug, not ours. The
> "but the user might not have freetype" argument is also invalid; they should
> go to the freetype website and download the thing then.
The last argument is VERY valid as it means that there are
prerequirements to build the Xorg tree which can only be fixed by being
an admin of the matching machine (you'll find not many environments
where people grant you root rights without any further explanations).
Installing extra source packages isn't always trivial in some
environemnts and that's one of the reasons why the current way of having
a self-contained build and development environment is still a good
thing.
> Likewise xterm. We don't need xterm for anything - nothing else in the build
> depends on it - and we don't apply any patches to it.
That is not 100% correct, the Xorg trunk version is AFAIK in sync with
Thomas Dickeys version.
> It's the perfect
> example of a modularised application. We have no reason to include or build
> it besides that we always have done so in the past.
What about those platforms which build&ship Xorg as one chunk (as AIX,
HP-UX do) ? And what about the old behaiour to build everything for
developers that they can do testing ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
More information about the release-wranglers
mailing list