Xorg 7: The new world order

[Adam Jackson]

On Thursday 22 December 2005 19:10, Mr E_T wrote:
> Would this be looked at seriously to be included as another source
> alternative ??

Why are you asking for permission?

These kinds of projects gain much more credibility when they exist first and 
_then_ ask for inclusion.  Doing things in that order both ensures that the 
developers of the project have sufficient interest to see it through to 
completion, and gives some idea of the size of the potential user base.

This is what we did with the original modularized X packages (xlibs, xapps, 
and debrix).

> I would consider adding a configure fragment to each package - say
> configure.semi-mod (.in would conflict with the existing configure script)
> than a configure in the base directory based on the merged
> configure.semi-mods

I think this is a bad idea technically.  It amounts to maintaining two build 
systems, and expecting developers to commit to both configure.ac and 
configure.semimod.ac (or else making one include the other, I suppose, which 
is still a bit confusing).

It would probably be better to do the semimod scripts by walking over the 
configure.ac and Makefile.am for each subpackage and sedding them together in 
the superpackage.  That would ensure that the superpackage's build scripts 
are always as correct as the subpackages it composes.

The technical problem with either approach is, someone has to decide which 
versions of each of the subpackages to include in each superpackage.  If you 
punt that decision to the user, then all you've really gained is a little 
automation, and I'd suggest just making jhbuild or build-from-tarballs.sh a 
little nicer as the Right Way to do that.  Whereas if you have a release 
manager for the superpackages, that's a whole new can of worms, and likely to 
lead to coordination hassles between the fully-modular and partially-modular 
RMs and also some end user confusion as to which packaging scheme is 
officially endorsed.

And then finally, I think the package breakdown you proposed is simply wrong.  
People just don't want to slice X at the level of "give me all the apps", I 
think.  Or if they do, they mean "give me all the apps except xdbedizzy", 
which becomes another configure option in the superpackage, and the argument 
reduces to the one above: you're attempting to automate, not repackage, and 
therefore you should be working from the automation we already _have_.

But hey, happy to be proven wrong.

> It would also help us kde'ers a lot :}

This seems like a total non-sequitur.  What do you mean by this?

- 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.x.org/archives/xorg/attachments/20051223/92598e9f/attachment.pgp>