[OE-core] [PATCH v2 1/1] buildtools-tarball: restore missing git tools

[Paul Eggleton]

Hi Peter,

On Saturday 06 December 2014 07:40:48 Peter A. Bigot wrote:
> On 12/06/2014 07:01 AM, Otavio Salvador wrote:
> > On Fri, Dec 5, 2014 at 11:39 PM, Paul Eggleton
> > 
> > <paul.eggleton at linux.intel.com> wrote:
> >> On Friday 05 December 2014 16:30:44 Otavio Salvador wrote:
> >>> On Fri, Dec 5, 2014 at 4:09 PM, Paul Eggleton
> >>> 
> >>> <paul.eggleton at linux.intel.com> wrote:
> >>>> Since the split out of git-perltools, some git tools (such as "git am",
> >>>> "git send-email" and "git-submodule") have no longer been part of the
> >>>> buildtools. We need these, so add them back in.
> >>>> 
> >>>> However, adding git-perltools to buildtools triggers perl itself being
> >>>> brought into buildtools as well, and we don't want that; but we also
> >>>> don't want to have to hack the git recipe or indeed anything else that
> >>>> starts depending on perl. Thus, add a dummy package which gets
> >>>> installed
> >>>> in its place, in a separate package architecture that is only enabled
> >>>> for buildtools to ensure it doesn't start appearing in place of
> >>>> nativesdk-perl anywhere else.
> >>>> 
> >>>> Fixes [YOCTO #7033].
> >>>> 
> >>>> Signed-off-by: Paul Eggleton <paul.eggleton at linux.intel.com>
> >>> 
> >>> This dummy thing looks like a hack to me :-(
> >> 
> >> Perhaps - I'm all ears for an alternative solution, but it absolutely has
> >> to be fixed, and soon. Shipping an incomplete git (or incomplete perl)
> >> in buildtools basically defeats a major part of having the thing in the
> >> first place.
> > 
> > We should split out the tools we really want (so we skip the perl
> > runtime dependency) or include perl. Use a dummy package for it is
> > wrong in my opinion. You cannot guarantee host perl will work as
> > expected for our git release.
> 
> I vote for "include perl".

We'd rather not do that for buildtools unless there are actual problems with 
the host perl. I've heard of no such issues up to this point.

> I was surprised that I had to submit a patch to get git-perltools to
> include the git Perl module which is required by git add --interactive.

Right, we have that dependency now though.

> Why are there things in git-perltools that don't have a true dependency
> on perl?  And if they do, then is the issue that some of them are usable
> in restricted ways that don't invoke that dependency?

There aren't. These require perl, but the host perl should be perfectly 
adequate. Buildtools isn't quite the same as the target.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre