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 127456
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: answered my own question
by Ookaze on Wed 24th May 2006 09:17 UTC 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

Ookaze Member since:
2005-11-14

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

Your life being easier depends on your package manager, not on the number of packages to push.
So no, I don't understand. Or rather, yes, I know there's a big packages creation time beforehand for the maintainer. I can't deny it, I've been through it.

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

So modularized X is good for you, as it solves this. So it's better now.

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...

XOrg was full of these kind of things. Fortunately, the modularisation allowed people to spot all of these.
So it's better now.

but telling us to track 280 releases instead of one, is not doing us a favour

You sound like it was doing them a favour. It took them months to do that and autotooling everything.
It was necessary IMHO, and I don't think they did it because they are masochists.
You meant tracking 280 packages I guess. There's far less than 280 releases for this 7.1 release for example.
And if I can track releases with one script and alone, I think any distro packager can do it too, with QA.
Some packages don't even need big QA, like fonts, or old rarely used X apps.
But don't worry, I don't think the monolithic release is abandonned, IIRC a 6.9.1 is on the way.

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)

I initially did that and a bunch of other symlinks for 7.0. Everything has been solved before 7.1 release though (which I still haven't installed, but I don't need more than 5 packages to update I think).

some packages are pretty stupid about this (vmware comes to mind) and won't be happy unless it's there

Then these packages have to be fixed. IIRC I patched xfce-session for this for example.
My desktops are now fully functional without any symlink anymore.

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)

Of course, but doing it and then have it work is something new.
Given all the hard paths removed in the XOrg code thanks to the modularisation, I doubt it would have worked (without the /usr/X11 symlink at least). Even the use of other fonts path (i.e. /usr/share/fonts) was implemented through symlinks in the monolithic package. I say no thanks : you removed them, and suddenly lots of packages that did not actually use the new paths stopped working.
For example, sth as essential as xterm, which is outside XOrg releases, had to be fixed.
Really, IMHO, the modularisation had a LOT of benefits already.

Reply Parent Score: 1