Hi, On Fri, Mar 17, 2023 at 03:25:10PM +0000, Alexander Kanavin wrote: > On Fri 17. Mar 2023 at 12.01, Mikko Rapeli <[email protected]> wrote: > > > Hi, > > > > On Fri, Mar 17, 2023 at 11:39:23AM +0100, Alexander Kanavin wrote: > > > This doesn’t seem right. We should not give special privileges to tooling > > > from any particular host distro. If you need to manipulate images, build > > > e2fsprogs-native and run that. > > > > This is about ext4 images breaking compatibility with older versions of > > tooling used manipulate the images. For Debian the upstream maintainers > > and Debian package maintainers agreed to keep the backwards > > compatibility for longer time. I think that makes sense for yocto too. > > > > While I agree that using e2fsprogs-native is a solution too, I also > > agree that a lot of users are using non-yocto e2fsprogs when e.g. > > flashing images to target HW. Breaking compatibility can quite simply be > > avoided and upstream will maintain this branch. Win win from my point of > > view. > > But then we should put e2fsprogs into buildtools-tarball(-extended). It’s > not any different to providing compatible gcc, when one from the host > distro is too old.
I think this one is a bit different. At flashing/install step people frequently manipulate rootfs images coming out of yocto builds to match what HW and various boards actually have, like extending the file system to fill full EMMC/SD cards. Like dd the .wic out of a build but extend the file system for the full disk before first boot on the system. > Taking a custom branch creates a maintenance problem. What if it stops > being maintained? Will it follow proper upstream closely? Can we ever drop > this backwards compatibility? It creates a long term headache that I do not > want. This branch is from upstream developers who are also the Debian package maintainers. Of course anything can break and no support can be guaranteed. https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=debian/master&id=1181f164c48574a4813bfa203dbd7b4123154021 "author Theodore Ts'o <[email protected]> 2023-03-04 22:04:29 -0500 Disable metadata_csum_seed and orphan_file by default for Debian There are a lot of debian packages that assume that mkfs.ext4 for Debian N will work on Debian N-1 (and sometimes N-2, N-3, etc.). This is a bad assumption, but it's too late to fix this for Debian Bookworm. So revert making these feature a default for now. We will enable it again post Bookworm. Signed-off-by: Theodore Ts'o <[email protected]>" That explains the timeline a bit. I think this is sensible to follow. If the branch dies and there are no more updates to CVEs etc triggers, then switching to master branch is ok. Right now the branch is actively maintained. Cheers, -Mikko
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#178799): https://lists.openembedded.org/g/openembedded-core/message/178799 Mute This Topic: https://lists.openembedded.org/mt/97669707/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
