Linked by Thom Holwerda on Tue 23rd May 2006 21:46 UTC, submitted by Joel Dahl
X11, Window Managers "Five months after release of X11R7.0, the modularized and autotooled release of the MIT Licensed X Window System source code, the X.Org Foundation has issued its first modular roll-up release. X11R7.1 supports Linux, Solaris, and BSD systems. It includes important new server and driver features for embedded systems, 64 bit platforms, enhanced operating system support, and accelerated indirect GLX support. It most importantly demonstrates to developers and industry immediate benefits of modularization."
Thread beginning with comment 127310
To read all comments associated with this story, please click here.
answered my own question
by macisaac on Tue 23rd May 2006 22:12 UTC
macisaac
Member since:
2005-08-28

sigh... I was hoping they'd still be releasing in parallel the fat tarball releases ala 6.9/7.0. while I can appreciate the technical reasons behind this for the X maintainers, and even perhaps for end users, however it looks to be a nightmare from a package maintainer's perspective.

with the old way, I have 1 (or divided into 7) tarball(s) to download. about one file, the host.def, to modify to taste, and then I compile it all in one go, and release as a collection all in one go. now I have about 280 packages to download, configure, compile, and release... not exactly fun.

Reply Score: 1

RE: answered my own question
by thebluesgnr on Tue 23rd May 2006 22:21 in reply to "answered my own question"
thebluesgnr Member since:
2005-11-14

You could simply use a script to build all packages.

Reply Parent Score: 1

RE[2]: answered my own question
by macisaac on Tue 23rd May 2006 22:45 in reply to "RE: answered my own question"
macisaac Member since:
2005-08-28

sure, I imagine one could do a

for i in `ls *`;
do cd $i;
./configure --prefix=/usr/local;
make;
make install;
cd ..;
done

after untarring them all (that's just a guess, I haven't messed around with the 7.x series yet. they do use autoconf now though right, not imake?). but what if there's different configure options to take in, how about parts being dependent on the others, build order dependencies and such? while the old way was a pain if you got one part wrong, or wanted to tweak with it, since it was such a large compile, it was still easier to manage than the current model.

I'm not saying it's the end of the X world for me, but it does mean alot more work next time I get around to packaging a new X (we're still using 6.8.2, and I don't see us going up for a while so no worries yet. but still...)

Reply Parent Score: 1

RE: answered my own question
by atomicplayboy on Tue 23rd May 2006 23:09 in reply to "answered my own question"
atomicplayboy Member since:
2006-04-28

Isn't the idea of the modularized xorg, that you don't have to release everything at once? Perhaps now, you might have a little more work to do, but when releases start happening seperatly for each module, wouldn't you only need to update what is in fact updated? In the release notes, they state that the release points (7.0, 7.1, etc...) are merely rolled up states of all the modules at certain designated times.

Reply Parent Score: 3

RE[2]: answered my own question
by Shaman on Tue 23rd May 2006 23:42 in reply to "RE: answered my own question"
Shaman Member since:
2005-11-15

All the in-between releases aren't considered to be stable. 7.1 as a whole is released as stable.

You'll see 7.1.x releases of various files for bugfixes now, and also 7.1.9xx as unstable development versions, if they do things the same way as they currently are.

Well, that's a bit simplified, but you get the idea.

Reply Parent Score: 1

RE: answered my own question
by leos on Wed 24th May 2006 00:07 in reply to "answered my own question"
leos Member since:
2005-09-21

now I have about 280 packages to download, configure, compile, and release... not exactly fun.

Are you seriously saying that they don't have an automated way to compile it all at once that takes care of dependancies? That would be ridiculous.

KDE has tons of modules and apps that you can compile separately, but that doesn't mean I have to do it that way. Just configure and make the master makefile and everything gets sorted out for you.

Reply Parent Score: 2

RE[2]: answered my own question
by macisaac on Wed 24th May 2006 01:31 in reply to "RE: answered my own question"
macisaac Member since:
2005-08-28

sadly, from the looks of it, that seems to be how it is. (I would love to be made wrong on this one...)

to get a feel for how complex this is, look at this:

http://lists.x.org/archives/xorg-modular/2005-November/000801.html

(btw since you mentioned it, I think the way the KDE devs setup their source tars is a _very_ good example of how things should be done in projects of that scale.)

Reply Parent Score: 2

RE: answered my own question
by Ookaze on Wed 24th May 2006 09:17 in reply to "answered my own question"
Ookaze Member since:
2005-11-14

I don't understand.
If you don't have an automated way to make releases, then you should not make releases, as human error can always happen (even in the original XFree), and lots of packages depend on X and where its elements are.

If you have an automated way to make releases, you just have more work to do once or twice to integrate the packages (the nightmare you talk about), and then you're set.
And it is easier afterward too. You're not compelled to keep some outdated packages. Like Mesa, which was always several versions behind, and that you could not really replace without risking crashes.
Or the fact that you downloaded tons of useless tools, or outdated versions of packages that you could replace fortunately (like expat, fontconfig, libfreetype, ...).

Frankly, it's way better now, I even got rid of /usr/X11 recently (everything is in /usr), and it works. I can use the latest Mesa, necessary for AIGLX (though I don't use it), I can use the latest freetype library, the latest far faster and reliable fontconfig development version (2.3.95).

I use the repository http://xorg.freedesktop.org/releases/individual/ with a script I made which updates the version numbers in my package system, tells me what I miss and what does not exist anymore. I thik that's a good packager resource.

Reply Parent Score: 2

RE[2]: answered my own question
by macisaac on Wed 24th May 2006 13:11 in reply to "RE: answered my own question"
macisaac Member since:
2005-08-28

I don't want to sound patronizing, that's not my intent, but unless you're doing this for a distribution that's being exported to multiple clients (in my case the college I work at) you won't be able to understand that this does _not_ make our lives easier. unfortunately I've found it much to common for instance for upstream providers to not get it in their head that people aren't always going to be installing their stuff locally, as a single user on their own machine would. Some devs don't even write in DESTDIR support into their Makefiles, or, decide they'll be really cool and write up their own unique build and install system say in python or something, which will be useless to someone like me...

I'm not saying the x.org folk are bad, and again I can understand why they needed to change the old model which was still using imake for goodness' sake. but telling us to track 280 releases instead of one, is not doing us a favour. (that said, this might not be the case. what I'm getting the feeling of is that there will be milestone releases saying 7.x (and all it's contents) is stable, use it, type of deal. I just prefer being able to use the older method where there was one download, and one file to configure to tell it what I do and don't want, and how I want it.)

oh about getting rid of /usr/X11, you might want to reconsider (or do what we did and make a symlink to /usr/local which is where our built stuff goes for the most part). some packages are pretty stupid about this (vmware comes to mind) and won't be happy unless it's there. anyhow, being able to specify your prefix for X isn't exactly something new. take a look at the old host.def file, there's a lot of things that you can tweak in there. (#define ProjectRoot is what your looking for)

Reply Parent Score: 1