[Buildroot] [PATCH 5 of 5] toolchain-external: use host-tar instead of tar to unpack toolchains

[Michael S. Zick <minimod@morethan.org>]

On Wed September 21 2011, Thomas De Schampheleire wrote:
> Hi,
> 
> On Wed, Sep 21, 2011 at 10:02 AM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> > Hello,
> >
> > Le Wed, 21 Sep 2011 08:55:35 +0200,
> > Thomas De Schampheleire <patrickdepinguin+buildroot@gmail.com> a ?crit :
> >
> >> Some toolchains, like the one built with buildroot itself, use hardlinks (for
> >> example to link between the c++ and g++ binary). Unpacking such a toolchain
> >> with the --strip-components options does not work correctly if the system tar
> >> is too old (<1.17). Even recent releases of RedHat/CentOS still ship with
> >> tar 1.15.
> >> To avoid such problems, always use host-tar instead of tar to unpack
> >> toolchains.
> >
> > I'm sorry but we need to find a better solution for this. I really
> > don't want all users to pay the price of building tar to extract
> > the external toolchain just because some crappy distribution has an old
> > version of tar. Can we make this conditional on the version of tar ?
> > I'd also like some comment in the code suggesting to remove this crap 1
> > or 2 years from now, once those RedHat/CentOS distributions will have
> > been upgraded.
> >
> > Also, this proposal only takes care of using the compiled host tar for
> > toolchain extraction. Why don't we also use it to extract all other
> > packages (except tar itself, of course...) ?
> 
> I agree with both your points. 
>

A suggestion here -
In that build system dependencies code/file, the one recently extended
to also list rsync...

Perhaps extend that with a bit of infrastructure that can check not
only if present (with which) but also the version?

That should help keep the build environment sane, with a message
to the user if something is too old;
And should relieve the maintainers of the task of remembering to
"re-correct" the build system someday in the future.

Mike
> In fact, I raised the same doubts in my 
> original patches:
> http://lists.busybox.net/pipermail/buildroot/2011-August/044784.html
> ----
> To be honest, I'm not sure what the best way is to handle this. The
> same problems with tar could occur in other places than just external
> toolchains. So maybe we should use host-tar in more places.
> On the other hand, most users have a recent, working, tar version on
> there system. It may thus make more sense to detect the system tar
> version and only use host-tar if it's too old.
> ----
> 
> 
> Regarding deprecating this change after some time: I'm not sure
> whether this is still necessary if we make this conditional on the
> system tar version. A user that is still on some old corporate system
> with RedHat 5, may still need this patch in two or three years.
> 
> I'll see if I can update this patch with an automatic detection.
> 
> How would you go about to use the host-tar for all packages? I need to
> add an extra autotargets call to package/tar/tar.mk, but I also need
> to redefine TAR somewhere (currently it's defined in
> package/Makefile.package.in). But TAR_STRIP_COMPONENTS uses TAR with a
> := dependency, and package/tar/tar.mk is only included after
> package/Makefile.package.in, so I would need to add the conditional
> check in two places.
> Unless I move the check to a new file that is included from both
> tar.mk and Makefile.package.in. In this case, where will I place the
> file?
> How do you see this?
> 
> Thanks for your comments,
> Thomas
> 
> >
> > Thomas
> > --
> > Thomas Petazzoni, Free Electrons
> > Kernel, drivers, real-time and embedded Linux
> > development, consulting, training and support.
> > http://free-electrons.com
> > _______________________________________________
> > buildroot mailing list
> > buildroot at busybox.net
> > http://lists.busybox.net/mailman/listinfo/buildroot
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 
>