Drop Xfree86 from the book

[Ag. Hatzimanikas]

I don't know any of the current editors that is still building Xfree,so there is no way to keep it updated.

If a user still wishes to build a monolithic X Window System he can always uses the last xorg-6.9.0 version.

So I suggest that XFree86-4.6.0 will be the last version that will be included in the BLFS-book.

[dnicholson@…]

This has come up a couple times, and the last time Andrew Benton stepped up and built XFree86 and made sure it worked. I never plan to build XFree86 again, but if Andrew wants to carry that torch I have no problem.

Regardless, this is a milestone for post-6.2. There's no good reason to rip it out now as 4.6.0 is tested to work.

[Randy McMurchy]

It appears that BLFS-6.2 is going to ship with both Xorgs and XFree as well

After that, here's how I see it. But this has been a frequent discussion item on -dev/-book, so the archives could be helpful to see other points-of-view.

A decision must be reached by the group about the need to keep anything but autotooled Xorg. I feel like the book needs an easy-building X for folks that may just need to do some testing (or whatever), and perhaps even intend to remove X at some point. Or, for that matter, just plain wish to use XFree instead of Xorg.

If it is determined that we keep a version of X that is based on the imake build system, then it seems to me that XFree would be the one. Reasons I see:

1. XFree will continue to be maintained (and if that were to ever change, then of course we would probably dump it).
2. Because nothing *requires* an imake installed version of X, it's hard to consider keeping two versions of Xorg around (such as the current GTK+ situation).
3. Xorg-6.x is no longer maintained.
4. There is much precedent in the book encouraging BLFS to maintain two (or more) flavors of similar (functionality speaking) packages if both/all are actively maintained.
5. Folks may wish to use XFree instead of Xorg.
6. I am on record as saying I would do the building and testing of XFree as we go forward. To me, it is trivial to test (shutdown current X, rename the current /usr/X11 and /etc/X11 dirs, install XFree, test). And as long as XFree continues to be maintained, it's likely that the actual code base will be updated to accomodate changes in hardware, etc. Therefore, it just seems to me to be a very low-maintenance thing with decent reward to the book.

[Randy McMurchy]

I'm ready to either close this bug as "won't fix", or change it to remove Xorg-6.9. I cannot see removing XFree86 until there's no more development in the project, but right now everything leads to a 4.7 release later this year.

Any reason we shouldn't pull Xorg-6.9 out now?

[bdubbs@…]

Do we know who is using xfree? What distros? What users?

I looked at the xorg website and I can't even see a way to browse the source to check out the amount of activity on the repository. They seem to have pulled the page that lists what distros use xfree.

Yes, IMO we should drop xorg-6 also.

[dnicholson@…]

I don't think any distros use XFree86, but the website is here is you want to try to find out:

​http://www.xfree86.org/

I'd be perfectly happy to drop Xorg-6 and XFree86, but I understand that some people want the monolithic build. Plus, XFree86 will always be stabler than Xorg for people that just want a window system and don't care about all the rest.

The problem with keeping XFree86 is that someone has to maintain it. Last time Andy did it. Do any of you guys use XFree? I'm strongly in the Xorg-7 camp and would build XFree only if I had to for the book.

[Randy McMurchy]

I will use XFree in my next build. I don't have any fancy hardware or extreme graphics, so I'm a perfect candidate to maintain it. I would like to keep it in the book, as long as it continues to be maintained (though there hasn't been a great amount of activity; ​http://xfree86.org/cvs/changes.html ) for the reasons Dan mention. Especially, for the quick and dirty installation some may desire.

[Randy McMurchy]

XFree is horribly broken against FreeType >=2.2.0. Many program sources contain calls to:

FT_INTERNAL freetype/internal FT_CACHE_INTERNAL

which are not available any longer in the API. The issue is discussed fully at: ​http://freetype.sourceforge.net/freetype2/freetype-2.2.0.html

There's no patch that I can find anywhere, and there's nothing in the XFree86 CVS tree that addresses this. XFree86 devs at this point need to really consider their using a dedicated version of FreeType piggy-backed along in the XFree86 source tree. It could be the death of the project.

I'll give them a couple of months, after that we'll be forced to remove XFree86 from the book.

[Randy McMurchy]

Oops!

[Randy McMurchy]

The Freetype update to version >=2.2.0 has been moved to the 6.3 milestone, therefore XFree can stay for the duration of the 6.2.x releases. So, moving to the 6.3 milestone.

[dnicholson@…]

I cobbled together a patch from upstream to fix the build with newer FreeType and got a tester to confirm it works.

​http://linuxfromscratch.org/pipermail/blfs-dev/2007-May/017191.html

That went in in r6774 along with a couple other fixes to make XFree86 usable.

I don't know what to change the status of this ticket to. The last conversation I recall decided that Xorg-6.9 would be removed and that XFree86 would be left. This would allow an option to those not interested in diving into the Xorg-7 modular build. In fact, Xorg-6.9 was removed a couple months ago.

[DJ Lucas]

I think 'won't fix -- not a bug' is good as long as somebody still wants to support it. *Does anybody volunteer to keep it up to date?* I'm out. Give it a week or two, if nobody takes responsibility, then kick it. Thought I doubt it, if a volunteer should come along later, it's not that big of a deal to get it back using a dated SVN checkout.

[DJ Lucas]

I suggested the deadline, 8 mos ago. Anybody want it, or does XFree86 only remain in the archived book? IMO, it's just extra weight on an already straining editor staff. Fix it once by kicking it and don't have to deal with it again.

[bdubbs@…]

Dropped XFree86 from the book. This was done mostly by commenting out the sections that referred to it, but leaving the ticket open because package contents in the XFree section still need to be ported to Xorg.

Committed revision 7177.

[bdubbs@…]

Fixed at revision 7177.