From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Martin Jansa <martin.jansa@gmail.com>,
"Bartosh, Eduard" <eduard.bartosh@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] e2fsprogs: Package populate-extfs.sh and enable symlink install
Date: Tue, 21 Apr 2015 07:24:51 +0100 [thread overview]
Message-ID: <1429597491.26983.66.camel@linuxfoundation.org> (raw)
In-Reply-To: <20150420130541.GD3686@jama>
On Mon, 2015-04-20 at 15:05 +0200, Martin Jansa wrote:
> On Fri, Apr 10, 2015 at 04:06:14PM +0200, Martin Jansa wrote:
> > * install populate-extfs.sh from contrib, be aware that in order
> > to use it you need to set DEBUGFS shell variable, otherwise it will
> > try to use debugfs from relative path which is almost always
> > incorrect:
> > CONTRIB_DIR=$(dirname $(readlink -f $0))
> > DEBUGFS="$CONTRIB_DIR/../debugfs/debugfs"
> >
> > * use symlinks to install e2fsck, mke2fs, without this option we have:
> > $ ls -lahi tmp-glibc/work/arm920tt-oe-linux-gnueabi/e2fsprogs/1.42.9-r0/image/sbin/
> > ...
> > 101982430 -rwxr-xr-x 5 bitbake bitbake 972K Apr 10 15:43 e2fsck
> > 101982430 -rwxr-xr-x 5 bitbake bitbake 972K Apr 10 15:43 fsck.ext2
> > 101982430 -rwxr-xr-x 5 bitbake bitbake 972K Apr 10 15:43 fsck.ext3
> > 101982430 -rwxr-xr-x 5 bitbake bitbake 972K Apr 10 15:43 fsck.ext4
> > 101982430 -rwxr-xr-x 5 bitbake bitbake 972K Apr 10 15:43 fsck.ext4dev
> > ...
> > 101982441 -rwxr-xr-x 5 bitbake bitbake 348K Apr 10 15:43 mke2fs
> > 101982441 -rwxr-xr-x 5 bitbake bitbake 348K Apr 10 15:43 mkfs.ext2
> > 101982441 -rwxr-xr-x 5 bitbake bitbake 348K Apr 10 15:43 mkfs.ext3
> > 101982441 -rwxr-xr-x 5 bitbake bitbake 348K Apr 10 15:43 mkfs.ext4
> > 101982441 -rwxr-xr-x 5 bitbake bitbake 348K Apr 10 15:43 mkfs.ext4dev
> > ...
> >
> > which would be OK, because they are hadlinks, but after runstrip in
> > do_package we get one stripped binary and 4 hardlinks to the original
> > one:
> >
> > $ ls -lahi tmp-glibc/work/arm920tt-oe-linux-gnueabi/e2fsprogs/1.42.9-r0/packages-split/e2fsprogs-e2fsck/sbin
> > 101982713 -rwxr-xr-x 8 bitbake bitbake 972K Apr 10 15:43 e2fsck
> > 101982713 -rwxr-xr-x 8 bitbake bitbake 972K Apr 10 15:43 fsck.ext2
> > 101982713 -rwxr-xr-x 8 bitbake bitbake 972K Apr 10 15:43 fsck.ext3
> > 101982713 -rwxr-xr-x 8 bitbake bitbake 972K Apr 10 15:43 fsck.ext4
> > 101983136 -rwxr-xr-x 2 bitbake bitbake 185K Apr 10 15:43 fsck.ext4dev
> > $ ls -lahi tmp-glibc/work/arm920tt-oe-linux-gnueabi/e2fsprogs/1.42.9-r0/packages-split/e2fsprogs-mke2fs/sbin/
> > 101982716 -rwxr-xr-x 8 bitbake bitbake 348K Apr 10 15:43 mke2fs
> > 101982716 -rwxr-xr-x 8 bitbake bitbake 348K Apr 10 15:43 mkfs.ext2
> > 101988266 -rwxr-xr-x 2 bitbake bitbake 72K Apr 10 15:43 mkfs.ext3
> > 101982716 -rwxr-xr-x 8 bitbake bitbake 348K Apr 10 15:43 mkfs.ext4
> > 101982716 -rwxr-xr-x 8 bitbake bitbake 348K Apr 10 15:43 mkfs.ext4dev
> >
> > That's super annoying for big files like this which are often include
> > in small recovery images. Using --enable-symlink-install option results
> > in one stripped binary and 4 symlinks:
> >
> > $ ls -lahi tmp-glibc/work/arm920tt-oe-linux-gnueabi/e2fsprogs/1.42.9-r0/packages-split/e2fsprogs-e2fsck/sbin/
> > 102113806 -rwxr-xr-x 2 bitbake bitbake 185K Apr 10 15:50 e2fsck
> > 102113813 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 fsck.ext2 -> e2fsck
> > 102113814 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 fsck.ext3 -> e2fsck
> > 102113812 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 fsck.ext4 -> e2fsck
> > 102113815 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 fsck.ext4dev -> e2fsck
> > $ ls -lahi tmp-glibc/work/arm920tt-oe-linux-gnueabi/e2fsprogs/1.42.9-r0/packages-split/e2fsprogs-mke2fs/sbin/
> > 102113804 -rwxr-xr-x 2 bitbake bitbake 72K Apr 10 15:50 mke2fs
> > 102113825 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 mkfs.ext2 -> mke2fs
> > 102113826 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 mkfs.ext3 -> mke2fs
> > 102113823 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 mkfs.ext4 -> mke2fs
> > 102113824 lrwxrwxrwx 1 bitbake bitbake 6 Apr 10 15:50 mkfs.ext4dev -> mke2fs
> >
> > Saving cca 1,5MB.
>
> Ping, this is needed also in fido and dizzy branches.
I'm still hoping we can fix the packaging code so that we avoid this
problem with hardlinked files which is why I'm holding off this
slightly.
Also, are you sure this problem applies in dizzy? The change the
introduced this problem wasn't in dizzy as far as I remember but I could
be wrong...
Cheers,
Richard
next prev parent reply other threads:[~2015-04-21 6:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-10 14:06 [PATCH] e2fsprogs: Package populate-extfs.sh and enable symlink install Martin Jansa
2015-04-10 15:01 ` Mark Hatle
2015-04-10 15:38 ` Martin Jansa
2015-04-10 16:10 ` Mark Hatle
2015-04-12 6:59 ` Khem Raj
2015-04-20 13:05 ` Martin Jansa
2015-04-21 6:24 ` Richard Purdie [this message]
2015-04-21 8:48 ` Martin Jansa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1429597491.26983.66.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=eduard.bartosh@intel.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox