Re: [PATCH] libfsimage: add ext4 support for CentOS 5.x

[Ian Campbell <Ian.Campbell@citrix.com>]

On Wed, 2012-09-05 at 21:55 +0100, Pasi Kärkkäinen wrote:
> On Wed, Sep 05, 2012 at 07:04:49PM +0100, Ian Campbell wrote:
> > On Wed, 2012-09-05 at 13:03 +0100, Roger Pau Monne wrote:
> > > CentOS 5.x forked e2fs ext4 support into a different package called
> > > e4fs, and so headers and library names changed from ext2fs to ext4fs.
> > > Check if ext4fs/ext2fs.h and -lext4fs work, and use that instead of
> > > ext2fs to build libfsimage. This patch assumes that if the ext4fs
> > > library is present it should always be used instead of ext2fs.
> > > 
> > > This patch includes a rework of the ext2fs check, a new ext4fs check
> > > and a minor modification in libfsimage to use the correct library.
> > > 
> > > Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
> > 
> > Thanks.
> > 
> > Any patch which is intended for 4.2 at this stage needs to come with
> > some rationale as to why it is acceptable at this late stage.
> > 
> 
> rhel5/centos5 has a lot of Xen users, so it'd be nice if those people
> could build Xen 4.2 from sources and still have pygrub ext4 support.

I'm sorry but two days (now one day) before the final RC we need more
justification than "it would be nice".

Who are these people? How many of them are there? Why are they doing
this? If you are building from source what reason is there to be using
RHEL5?

We certainly don't seem to be getting bugs reports (either on -devel@ or
-users@) about this problem.

> (the stock redhat el5 Xen 3.1.2 rpms have similar tweaks and 
> they do provide pygrub ext4 support out-of-the-box on el5).
> 
> Also XenServer/XCP has hacks to get pygrub ext4 support enabled in similar way,
> so it'd make sense to fix/workaround this properly in Xen upstream.

This seems right and proper to me and isn't an argument for us taking
and carry this hack in our tree.

IMHO the presence of libe4fs in RHEL5 is a distro specific packaging
hack and it is appropriate that the fallout be dealt with via RHEL5
specific packaging hacks.

> > Therefore unless someone can argue convincingly for it this is 4.3
> > material.
> > 
> 
> I'm not expecting that was convincing enough :) so if not 4.2.0 then 4.3 and 4.2.1 ? 

Perhaps. I'm not entirely convinced of the need at all though. If RHEL5
was the current release then maybe, but RHEL6 is nearly two years old at
this point.

Ian.