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

[Otavio Salvador]

On Sat, Dec 6, 2014 at 12:37 PM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Sat, 2014-12-06 at 11:01 -0200, 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.
>
> There needs to be a mechanism where we draw the line on which
> dependencies a given thing has. Perl is arguable both ways. In all cases
> I'm aware of, the host perl is generally API stable and works fine with
> buildtools.
>
> If you don't buy the perl argument, think about bash. Should we ship
> bash in case anything in the buildtools tarball? Should we alter all
> script paths to point at our own "sh"?
>
> At some point you have to depend on the host system, be it perl, sh or
> other things. The exact line should be configurable, Paul is simply
> adding a mechanism here that allows us to control that. He's needed a
> default and I think perl is API stable enough that we should be ok here.

I understand but the provided mechanism is ugly and hackish.

Maybe a mechanism like 'ASSUME_PROVIDED' could be made and use for
this use-case. A dummy package looks like a workaround.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750