Re: [PATCH 0/7] Let user specify the kernel version for features

[Anand Jain <anand.jain@oracle.com>]

Hope we are in sync on..

1.
The term auto that you are using here refs to
  'Progs default-features being updated at the _run time_'.

2.
In the long run, mostly it would be:
   progs-version > LTS-kernel-version
(for the reason that user would need fsck,tools.. etc)


>>>>> With the new -O comp= option, the concern on user who want to make a
>>>>> btrfs for newer kernel is hugely reduced.
>>>>
>>>> NO!. actually new option -O comp= provides no concern for users who
>>>> want to create _a btrfs disk layout which is compatible with more
>>>> than one kernel_.  above there are two examples of it.
>>>
>>> Why you can't give a higher kernel version than current kernel?
>>
>>   mount fails.  Pls try !!
>
> But that's what user want to do. He/she knows what he is doing.
> Maybe he is testing btrfs-progs self test without the need to mount
> it(at least some of the tests doesn't require mount)

  right. It will continue to fail even with this patch set.


> Now we need to auto align feature with kernel, who know one day we will
> need to auto align our libs to upstream package?

  align libs to upstream package ? is there any eg you could provide ?


> Keeping a matrix with different packages like libuuid/acl/attr with
> different Makefile?
> At least this is not a good idea for me, and that's the work of
> autoconfig IIRC.
>
> And if I'm a package and face such problem, I'll choose the simplest
> solution, just add a line in PKGBUILD(package system of Archlinux) of
> btrfs.
> ------
> depends=('linux>=3.14')
> ------
> (Yeah, such simple and slick packaging solution is the reason I like
> Arch over other rolling distribution)
>
> Not every thing really needed to be done in code level.

  As we are handling default features at the run time, how is
  this relevant in this context. ?

Thanks, Anand