Xorg 7: The new world order
ajax at nwnk.net
Fri Dec 23 10:26:27 PST 2005
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,
> 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
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg