Xorg 7: The new world order

[Mr E_T]

On Friday 23 December 2005 01:18, Alan Coopersmith wrote:
> Mr E_T wrote:
> > Its a shame that when XOrg went modular that they went too far.
> > 6.9 is probably the last XOrg version that I will use.
> > 7.0 it too modularised for me.
> > Too much of a pain to build.
> > Too many sources.
> 
> Yes, there is a lot - but after the one-time initial pain of
> building them all once, many shouldn't need to be rebuilt again
> for a long time, if ever.  Do you really rebuild all your fonts
> that often?
> 
> If enough people agree with you, it will be much easier for you
> to band together and build meta-packages that combine the Xorg
> packages into larger packages that you download and build as a
> single unit than it would be for those who want more granularity
> to break it down further if we had broken into bigger chunks.
> It's not inconceivable in fact that someone could regenerate a
> complete monolith tarball of all the sources from a rollup release
> using a script like the build.sh in Xorg CVS to build them all as
> a single unit.
> 
> If not, then I hope 6.9 works for you forever and you don't ever
> buy a new graphics card that it doesn't support.
> 
First of all I will admit to becoming so frustrated as to spit out
inconsidered comments.
I believe that XOrg is superior to XFree86 codewise
for example - XFree doesnt include experimental drivers like
unichrome/openchrome at all.

I use a LFS system and already manage 500+ packages on my system.
I use checkinstall + rpm to manage backups and package removal.
I don't use gnome because of the extremely complicated build/install
process.

NOW-

If Someone was to provide a set of config scripts/setups to package a
semi-modular xorg - ie
XOrg-docs
XOrg-protocols
XOrg-libs
XOrg-apps   ( Including data - too interlocked - maybe they should be
              merged in cvs ? )
XOrg-drivers ( I would probably include the server in this one too )
XOrg-fonts
XOrg-utils

extras would does not need to be included.

Would this be looked at seriously to be included as another source alternative ??

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

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

-- 
regs MR E_T
_______________________
\                      \
  \   OOHH I hate TYPOS  \
    \                      \
      ~~~~~~~~~~~~~~~~~~~~~~~