Call Monday 24 Jan 2005

[Adam Jackson]

On Tuesday 25 January 2005 18:16, Roland Mainz wrote:
> > 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.

This sounds like you're saying "these pieces of functionality that xrx needs 
don't have a shared library implementation."  Once again I fail to have much 
pity for technology that is incapable of defining its components clearly.

Orthogonal to this, many of the components in question are widely considered 
to be a Bad Idea.  LBX is not an effective solution for low-bandwidth links.  
Security is unmaintained since forever, and is generally incompatible with 
modern toolkits - try running ssh -X sometime to find out just how 
incompatible.  New applications are not written in Xaw.  No one even knows 
what appgroup does.  These pieces do not get used on a modern X desktop.  
Perhaps there's a reason for this.

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

As I read it, Keith said there has been no other place to get xrx.  This is 
not the same thing as there will never be any other way to get xrx.

xrx not being included in 6.8 was an excellent opportunity to say "xrx users 
can now get their bits in this one tidy little package".  Instead you chose 
to require xrx users to reinstall all of X.  From a user standpoint, that's 
not particularly friendly.  But whatever, you're the maintainer, your 
decision.

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

Has it ever occurred to you that if no one cares about a particular piece of 
the tree, it may be for a very good reason?

Corollary: Splitting off the source into an independent package takes roughly 
the same amount of time as fixing it within the existing build system.  I 
speak from experience here.

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

I will speak slowly, using small words, because I think this is an important 
concept for us all to understand:

Those.  Platforms.  Are.  Broken.

Full stop.

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

This is exactly my point; I don't know how many times you're going to refuse 
to get it.  It is a waste of engineering effort, on both sides of the game, 
to continue to copy Dickey's source into programs/xterm.  It means more 
patches for us to apply, and it means more time he spends saying "their 
version is old and buggy, mine works better, use mine instead".

If our xterm is identical to his xterm, then why does our xterm exist?

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

What about them?  They change their build system to match the new reality, and 
they continue to build up a /usr/X11R6 tree, tar it up, and send that to 
customers.  If they want to continue shipping the world as one big chunk, let 
them.  Nothing prevents this; in fact defining the set of pieces that compose 
"The X11RWhatever Release" is an integral goal of m12n, because the current 
policy of "whatever happens to be under xc" sucks, sucks, and also, sucks.

I think what you'll find is that the _vast_ majority of the pieces in 
programs/ simply do not get used.  And the ones that get used, do not get 
changed (xterm excluded).  Ship only what you need, and only what your 
customers need.  No one needs bdftopcf.  No one needs xedit.  I might need 
xdpyinfo, but I only need it once, because it doesn't change.

> And what about the old behaiour to build everything for 
> developers that they can do testing ?

As a developer, I want the world to build as little as possible, because at 
any given moment I care only about the one piece I'm working on.  If I really 
want to build everything in the world:

cd ${xapps}
for i in */
do
 pushd $i
 make
 sudo make install
 popd
done

It's _trivial_.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/release-wranglers/attachments/20050125/2ef1357a/attachment-0001.pgp