Re: [PATCH 1/1] e2fsprogs: 1.42.9 -> 1.43-WIP

[Robert Yang <liezhi.yang@windriver.com>]

On 01/18/2016 03:31 PM, Patrick Ohly wrote:
> On Fri, 2016-01-15 at 11:15 +0000, Richard Purdie wrote:
>> On Thu, 2016-01-14 at 18:05 -0800, Robert Yang wrote:
>>> Upgrade to 1.43-WIP to make "mke2fs -d" support xattr, so that the
>>> layer
>>> which requires xattr such as meta-selinux can populate images easily.
>>>
>>> * Remove the following patches since they are alredy in the source.
>>>    0001-e2fsprogs-fix-cross-compilation-problem.patch
>>>    0001-libext2fs-fix-potential-buffer-overflow-in-closefs.patch
>>>    0001-mke2fs-add-the-ability-to-copy-files-from-a-given-di.patch
>>>    0002-misc-create_inode.c-copy-files-recursively.patch
>>>    0003-misc-create_inode.c-create-special-file.patch
>>>    0004-misc-create_inode.c-create-symlink.patch
>>>    0005-misc-create_inode.c-copy-regular-file.patch
>>>    0006-misc-create_inode.c-create-directory.patch
>>>    0007-misc-create_inode.c-set-owner-mode-time-for-the-inod.patch
>>>    0008-mke2fs.c-add-an-option-d-root-directory.patch
>>>    0009-misc-create_inode.c-handle-hardlinks.patch
>>>    0010-debugfs-use-the-functions-in-misc-create_inode.c.patch
>>>    0011-mke2fs.8.in-update-the-manual-for-the-d-option.patch
>>>    0012-Fix-musl-build-failures.patch
>>>    CVE-2015-0247.patch
>>>    copy-in-create-hardlinks-with-the-correct-directory-.patch
>>>    fix-icache.patch
>>>    misc-mke2fs.c-return-error-when-failed-to-populate-fs.patch
>>>
>>> * Remove cache_inode.patch since it is not needed any more
>>>
>>> * Updated mkdir.patch and ptest.patch
>>>
>>> * Add --enable-libblkid to EXTRA_OECONF since libblkid is not created
>>> by
>>>    default.
>>>
>>> * Time of core-image-sato-sdk do_rootfs:
>>>    - Before upgrade
>>>      real    3m18.508s
>>>      user    7m42.088s
>>>      sys     1m1.984s
>>>
>>>    - After upgrade
>>>      real    3m21.552s
>>>      user    7m38.496s
>>>      sys     1m0.644s
>>>
>>>     The are nearly the same
>>>
>>> * The "fsck -fn" shows the image is OK, and also can boot.
>>>
>>> [YOCTO #8622]
>>>
>>> Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
>> [...]
>>
>>> -SRC_URI[md5sum] = "3f8e41e63b432ba114b33f58674563f7"
>>> -SRC_URI[sha256sum] =
>>> "2f92ac06e92fa00f2ada3ee67dad012d74d685537527ad1241d82f2d041f2802"
>>> +SRCREV = "0f26747167cc9d82df849b0aad387bf824f04544"
>>> +PV = "1.43-WIP+git${SRCPV}"
>>
>> What happens when 1.43 is released? 1.43 < 1.43-WIP so we'd have to
>> bump PE.
>>
>> Can we just call this 1.42+1.43-git${SRCPV}?
>
> However, that is not a more recent version than the one that was in
> OE-core before:
>
> $ dpkg --compare-versions 1.42+1.43 gt 1.42.9 && echo greater || echo less
> less
>
> As a result, the version upgrade (which is in OE-core master now) became
> a downgrade as far as distros with stable package feeds are concerned,
> didn't it?
>
> The version for OE-core could have been: 1.42.9+1.43-git${SRCPV}
>
> However, I've had a "1.42.9+git${SRCPV}" in meta-intel-iot-security for
> a while now, and 1.42.9+1.43-git${SRCPV} is considered older than that
> because of the embedded 1.43. While I understand that external layers
> should not be something that OE-core needs to be concerned about too
> much, some consistency still helps.
>
> I believe the "1.42.9+git${SRCPV}" string goes back to Ross, so I'd
> assume that it is not too unusual. Can we perhaps use "1.42.9+git
> ${SRCPV}" also in OE-core? Then if I'm not mistaken, the magic behind
> ${SRCPV} will ensure that the final version number will be higher.

Maybe use 1.42.13+git${SRCPV} ? Since 1.42.13 is the lastest 1.42 version.

// Robert

>