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

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Anand Jain wrote on 2015/11/27 06:17 +0800:
>
> 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_'.

Yes.

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

Also true.

But mkfs default features won't change during one or two LTS kernels.

>
>
>>>>>> 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 ?

IIRC, for the ancient time, libblkid is still included in e2fsprogs and 
its API is different from nowadays.

Will us need to support that one with different blkid calls?

>
>
>> 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. ?

I meant, it can be done in packaging level and it's much easier to do.
One dependency line vs near 200 codes.
And it's much predictable than version based detection.

Thanks,
Qu

>
> Thanks, Anand
>
>
>
>