RHEL5 LTSP5 backport problems

[Peter Scheie]

I don't know much about how repositories are maintained, but for Scenario 1, 
could the Fedora chroot be upgraded as new releases of Fedora come out?  Or, 
since we build an entire Fedora chroot, how hard will it be to use new versions 
of Fedora to (re-)build the chroot?

Peter

Warren Togami wrote:
> So I'm plugging away at a RHEL5 backport of Fedora 9's LTSP5.
> 
> Big problems...
> 
> 1) RHEL5 (and CentOS) has a minimum of i686 kernel.  There is no i586 
> kernel.  I suppose this is a pretty big deal because i586 thin clients 
> are still being sold new today.  (AMD Geode, eBox/LTSP Term 1000, 
> anything else?)
> 2) We cannot backport necessary changes to mkinitrd and push it in an 
> official RHEL5 errata because the changes needed for thin clients are 
> too invasive.
> 
> Options?
> 
> Scenario 1: Fedora in Chroot
> ============================
> I am considering that a RHEL5 LTSP server might be better off with a 
> Fedora client chroot in /opt/ltsp/i386.  The server side would remain 
> entirely RHEL + EPEL, while the client would be Fedora.
> 
> Here is the line of reasoning...
> 
> * Fedora provides the i586 kernel.
> * The Fedora X drivers have fewer problems on prevalent thin client 
> hardware since they are newer and we put work into testing/fixing them 
> with actual thin client hardware.
> * Since mkinitrd and kernel guarantee that you need an "unofficial" 
> package replacing a RHEL core component in the chroot anyway, why not 
> make the entire chroot "unofficial"?
> * This allows us to focus our limited LTSP R&D resources on a single OS 
> (at least for the client).  This significantly reduces the development 
> and testing burden.
> * DRAWBACK: This is not a good solution because Fedora has updates for 
> only ~13 months.
> 
> Scenario 2: RHEL5 chroot
> ========================
> * Somebody has to perpetually maintain an unofficial kernel.i586 that 
> stays in sync with RHEL5.  This cannot be a fully automatic job, and 
> nobody wants to be stuck doing this for 5 years.
> * mkinitrd plus patches from Fedora 9 would need to be maintained 
> unofficially and used only in the client chroot.  For 5 years.
> * Both of these are EXTRA WORK that I or other people wouldn't be 
> otherwise doing.  Any time we spend on this distracts away from new 
> development.
> 
> It is POSSIBLE than this second scenario is actually a good idea, but I 
> fear this is unrealistic given our resources today.
> 
> Thoughts?
> 
> Warren Togami
> wtogami at redhat.com
> 
> _______________________________________________
> K12Linux-devel-list mailing list
> K12Linux-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/k12linux-devel-list
>