On Mon, Feb 07, 2022 at 12:05:41PM +1100, Dave Chinner wrote: > On Fri, Feb 04, 2022 at 04:36:18PM -0800, Darrick J. Wong wrote: > > On Fri, Feb 04, 2022 at 05:18:12PM -0600, Eric Sandeen wrote: > > > On 1/19/22 6:21 PM, Darrick J. Wong wrote: > > > > From: Darrick J. Wong <djwong@xxxxxxxxxx> > > > > > > > > Move our private copy of the GETFSMAP definition into a libfrog header > > > > file that (preferentially) uses the system header files. We have no > > > > business shipping kernel headers in the xfslibs package, but this shim > > > > is still needed to build fully functional xfsprogs on old userspace. > > > > > > Hm. Fine, but I wonder if we can get a bit more intentional about how > > > we handle this kind of thing, I understand why we copy this stuff into > > > xfsprogs early, but then we never know how to get rid of it. > > > > > > Do we /need/ to build fully functional xfsprogs on old userspace? > > > (really: systems with old kernel headers?) How far back do we go, > > > I wonder? Anyway... > > > > TBH we could probably get rid of these entirely, assuming nobody is > > building xfsprogs with old kernel headers for a system with a newer > > kernel? > > Just fiddle the autoconf rules to refuse to build if the system > headers we need aren't present. It just means that build systems > need to have the userspace they intend to target installed in the > build environment. GETFSMAP premiered in 4.12, so I'm going to take this response (and the lack of any others) as a sign that I can respin this patch to require recent kernel headers instead of providing our own copy. --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
