Xorg 7: The new world order

[Mr E_T]

This was the sort of discussion I was hoping for when I posted that.
I just got so wound up I let myself go.
I apologise for any offence that I may have caused.

On Saturday 24 December 2005 02:26, Adam Jackson wrote:
> 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?
Because I was trying belatedly to pull mu head in and be polite.
I also didn't want to waste my time on something that was going
to be dismissed out of hand.

> 
> 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).
Maybe - But I had no Idea where to start in that area.

> 
> > 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.
Due to present configure scripts looking for dependency apps this would not be
the best recourse - I did consider it. I also tried to consider what the least
intrusive option would be. 1 single file in the subtree would not need to be excluded
in any way from a single release.

> 
> 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.
At the moment there is a planned release cycle for XOrg as a whole - simply put
all packages are released together. - On a release - package the cvs trees in
both ways.

> 
> 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_.
a simple switch eg. --without-xterm would solve this

> 
> But hey, happy to be proven wrong.
I have built KDE many times - they use this semi - modular approach
I for one do prefer this method. It keeps the dependencies in order

Also libs utils apps etc, would  generally all be built
its the drivers that tend to be chosen separately - you can install the semi-mod
versions of the libs utils etc and then install a particular driver without breaking 
anything.

> 
> > It would also help us kde'ers a lot :}
> 
> This seems like a total non-sequitur.  What do you mean by this?
I was still a little frustrated but I was referring to the few source/binary packages
vs a lot of source/binary packages.
Even when I was using a distribution - I still didn't install gnome - the package
breakdown seemed too confusing even that way.
Appart from the confusing configure problem with XOrg monolithic - I liked it because 
It was 1 download - 1 build

I like the semi-monolithic approach for the same sort of reason.

but when you need to organise a lot of downloads - a lot of builds - probably through
a firewall - at a particular time ( to avoid excess downloads fees ) then it gets
interesting - I am not saying that the modular approach will pollute my system - just
my sanity.

Build scripts are all well and good - but again they run into the problem above - the
author decides which package versions to use etc.

Why not just provide an alternative source build type and let the downloader decide?

They would probably mix n match the semi-modular and the full modular - depending on
their own circumstances

I use 3 different drives at home - with the possibility of others. - I would probably
download the semi modular versions of all modules. But someone who only has need of 1
driver would probably just download that 1 module.

Please excuse my syntax/terminology - I have trouble with writing things down.

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