[OE-core] [PATCH 1/1] opkg-build: Ignore tar error due to hardlinks issue when creating ipk files

[Richard Purdie]

On Mon, 2015-07-06 at 18:20 -0300, Otavio Salvador wrote:
> Hello,
> 
> On Mon, Jul 6, 2015 at 6:16 PM, Gary Thomas <gary at mlbassoc.com> wrote:
> > On 2015-07-06 15:10, Alejandro Hernandez wrote:
> >>
> >> On 06/07/15 15:10, Martin Jansa wrote:
> >>>
> >>> On Mon, Jul 06, 2015 at 10:17:19AM +0000, Alejandro Hernandez wrote:
> >>>
> >>> +
> >>> +This a similar behavior to the one on dpkg:
> >>>
> >>> +http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=40731942515ec8d80c727ad561174986d4f05818
> >>> +
> >>> +Upsteam-Status: Inappropriate
> >>> Typo and why is it inappropriate? Looks like bugfix to me, even for
> >>> issue which usually happens in OE way of using opkg-build.
> >>
> >>
> >> It seemed inappropriate to me, since this behavior is not expected (number
> >> of hardlinks changing), we can't say for sure that this error will be caused
> >> by this reason on when using
> >> opkg on another environment
> >>>
> >>> -SRC_URI = "git://git.yoctoproject.org/opkg-utils"
> >>> +SRC_URI = "git://git.yoctoproject.org/opkg-utils "
> >>> +
> >>> +SRC_URI_append_class-native = "file://tar_ignore_error.patch"
> >>> Add leading space in append not in original SRC_URI variable.
> >>>
> >>> Why is it applied only for native anyway?
> >>
> >>
> >> Same argument as before, modifying the number of hardlinks while the tar
> >> is created happens when building using bitbake, which should not happen on
> >> target, if files changed when
> >> creating an ipk for any other reason it shouldn't be ignored; space was a
> >> typo
> >
> >
> > Why is it happening when using bitbake?  This seems like an
> > error to me - one should not be generating the tarball (i.e.
> > packing up the final results) if the set of files being packaged
> > is changing in any way.
> >
> > Note: I'm pretty sure that error can also happen if the inode
> > changes in many different ways, not just the number of links
> > changing.
> 
> I fully agree with Gary; this also makes unreproducible the number of
> shared hard links in a final rootfs which is also important.
> 
> This (and dpkg related patch) seems to be covering the real bug.
> 
> (Adding Richard so he can also comment on this and to bring his
> attention to the concerns exposed here)

The issue here is some of the attempts to decrease disk usage and
increase the build speed. To do that we hardlink files in the package
directories rather than create individual copies in packages/ and
package-split/. There are cases where other parts of the build (e.g.
populate-sysroot) can create or remote copies of the hardlinked file
which changes the link count.

The files themselves do not change, only the link does and then only
rarely. We fixed dpkg a while ago for this issue, this is the same fix
being applied to opkg-build. The resulting packages will be the same
since the hardlink count is internal to the tarball and not related to
the number of original file copies. Since we control the build env, it
is safe to do what we're doing here, however I would agree with
Alejandro that it isn't something upstream would want to do.

Cheers,

Richard