[Android-tools-devel] Would Be Better to Package android-platform-external-f2fs-tool?

[Hans-Christoph Steiner]

Hey seamlik,

The best outcome would be to get the changes we need into the upstream
f2fs-tools.  That makes it easy to then get those changes into Debian's
f2fs-tools as an NMU or official upload.  Since you've done most of that
work in your patch, let's try to get that patch upstreamed into
f2fs-tools.  I'm sending an email to start that discussion now.

Next up would be to simplify your f2fs-tools package as much as
possible.  I think if your patch just make a static library, it would be
much simpler to review and manage, and it would work fine for the
Android Tools stuff.

Otherwise, we can go with android-platform-external-f2fs-tools, that
sounds like a good plan for making more progress.  That does not prevent
us from switching to f2fs-tools in the future.  But since it is a new
package, it will have to go through the NEW queue, and it could be
rejected there since it is just a repackaging of f2fs-tools.

.hc

殷啟聰:
> Hi all,
> 
> f2fs-tools is now the only thing that blocks our entire first step of
> uploading Android SDK. Actually the stage1 of
> android-platform-system-core can be uploaded without the patched
> f2fs-tools, but thus it won't have fastboot. Since the maintainer of
> f2fs-tools seems to lack enough time for the package, and I don't want
> android-platform-system-core to stuck in stage1 for too long, I think
> packaging android-platform-external-f2fs-tools would be better.
> 
> So far I am not aware that AOSP's f2fs-tools has any Android-specific
> modifications, so I assume it is merely a clone from upstream. However
> there are one difference between AOSP version and the upstream:
> fastboot requires libf2fs_fmt which is not intended to be built in the
> upstream. See <https://android.googlesource.com/platform/external/f2fs-tools/+/refs/tags/android-6.0.0_r26/Android.mk>.
> 
> Packaging AOSP f2fs-tools only takes no more than half an hour, and
> after that we can start uploading many AOSP packages, which are quite
> ready so far.
> 
> Regards,
> Kai-Chung Yan
>