[packagers] Re: Building packages for rpmforge

Jesse Hathaway jesse at mbuki-mvuki.org
Mon Jan 31 21:41:57 CET 2011

Yury V. Zaytsev <yury at ...> writes:
> This doesn't quite fit with the notion of backporting X.Org. I think this
> will void your support contract with Red Hat, but even in the case if I am
> mistaken you will have to keep updating X.Org on your own to keep your
> systems secure and this involves quite a lot of work.

But isn't that the same issue with replacing any RHEL core component with a
build from RPMForge?

> Also, I think that newer X.Org will require newer kernel interfaces, which
> means that you will have to build your own kernels, not even just adding
> patches on top of RH supported kernel, but rebuilding Fedora kernels.

I mentioned that I would be using a newer kernel as well

> I think this might have severe implications on the stability of the system,
> since say RHEL 2.6.18 kernel is nothing like vanilla 2.6.18 kernel and the
> userland is dependent on specific kernel interfaces which it expects to
> behave in a certain way.

My understanding is that the linux kernel goes to great lengths to be backward
compatible with userland. Anecdotally I have never had an issue running a new
kernel on an old distribution.

> All in all, I think this is definitively a very very bad plan.

Would you please elaborate as to why backporting X.Org is a very very bad plan?
What makes X.Org different from all the other packages that are being
backported by RPMForge?

> For starters, why didn't you consider kabi tracking mods? Are you sure that
> newer drivers that you need can not be just backported to kernel 2.6.18 as a
> kmod and build against older X.Org interfaces, such as those provided by
> ElRepo?

I would need to backport the DRM kernel layer as well. My gut feeling was that
backporting graphic card kernel drivers would require much greater technical
knowledge that backporting X.Org.

> Why didn't you consider RHEL 6 by the way and are talking about RHEL 5.5 in
> your posts? I think kernel 2.6.32 and RHEL 6 X.Org are pretty recent so they
> most probably they already support your newer hardware out of the box.

At present we are using 5.5 so 6 is not an option. Even if it were however, the
exercise is still valuable as even Ubuntu is struggling to use 2.6.32 with
current hardware, http://www.phoronix.com/scan.php?page=news_item&px=Nzk5Nw


More information about the packagers mailing list