On Sat, Dec 6, 2014 at 12:37 PM, Richard Purdie <[email protected]> wrote: > On Sat, 2014-12-06 at 11:01 -0200, Otavio Salvador wrote: >> On Fri, Dec 5, 2014 at 11:39 PM, Paul Eggleton >> <[email protected]> wrote: >> > On Friday 05 December 2014 16:30:44 Otavio Salvador wrote: >> >> On Fri, Dec 5, 2014 at 4:09 PM, Paul Eggleton >> >> >> >> <[email protected]> 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 <[email protected]> >> >> >> >> 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 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
