[Buildroot] [PATCH 1/4] core/pkg-infra: introduce download features concept

Arnout Vandecappelle arnout at mind.be
Tue Jan 21 22:21:08 UTC 2020



On 20/01/2020 22:26, Vincent Fazio wrote:
> Arnout,
> 
> On 1/20/20 3:07 PM, Arnout Vandecappelle wrote:
>>
>> On 20/01/2020 21:38, Vincent Fazio wrote:
>>> Arnout, Yann, et al
>>>
>>> On 1/20/20 2:56 AM, Arnout Vandecappelle wrote:
>>>> On 17/01/2020 17:44, Yann E. MORIN wrote:
>>>>
>>>> [snip]
>>>>> At some point in the past, Arnout expressed some concern about adding yet
>>>>> more variables,
>>>>    That was more about internal variables, not user-facing variables. And also
>>>> about variables that are actually assigned to. Each variable that is set in
>>>> inner-generic-package gets multiplied a thousandfold and this puts pressure on
>>>> the internal tables in make.
>>>>
>>>>> and this feature thingy would be the opportunity to
>>>>> coalesce many variables into a single one (or rather, avoiud adding new
>>>>> variables).
>>>>    Iff there are several users of it. So, as I said, it's a good idea if we
>>>> get 4
>>>> features.
>>> So it sounds like this is too much infrastructure change until we have 4
>>> definitive use-cases.
>>>
>>> At this time, we only have one (git submodules). My intent with this series was
>>> to add the foundation for supporting git-lfs (which would be the second
>>> use-case) and others.
>>>
>>> Based on the conversation, it seems like until we have a hard requirement from
>>> other backends (hg and svn as previously mentioned), this series is DOA and that
>>> git-lfs support should be added via some <pkg>_GIT_LFS define as was originally
>>> submitted here:
>>> http://lists.busybox.net/pipermail/buildroot/2018-April/219716.html
>>>
>>> My main goal here is to add git-lfs support, regardless of how that needs to
>>> happen. If resubmitting the original patch gets that done, that's what I'll do.
>>   Yes, I think the original patch should be fine. Just also add git-lfs to
>> DL_TOOLS_DEPENDENCIES, and test if it still works correctly if you don't have
>> git-lfs installed on your host.
> 
> I have a series staged here with most of that support:
> https://gitlab.com/vfazio/buildroot/merge_requests/4/commits
> 
> I opted to create a host package for git-lfs in the case the host was missing
> it.. but can drop that if we'd rather enforce the host to have it pre-installed.
> 
> I was a bit confused on the difference between DL_TOOLS_DEPENDENCIES and
> <PKG>_DOWNLOAD_DEPENDENCIES and opted for the latter, but can change that.

 DL_TOOLS_DEPENDENCIES means that we check if the tool is already installed on
the system.

 <PKG>_DOWNLOAD_DEPENDENCIES means that the host-tool will be built (and the one
on the system is never used, unless you add check-host-git-lfs support).

 Personally I think for something like git-lfs we can expect it to be installed
on the system, since it will probably never be used by any in-tree package. IOW,
I think DL_TOOLS_DEPENDENCIES is the easiest and good-enough solution.


>>   Ideally there should also be a package in-tree that uses it, but I can imagine
>> that it will be hard to find one... Failing that, a test case would be nice -
>> but again, that may be difficult to implement without relying on some
>> server-side support for it.
> As you mention, a test case will be difficult without a server implementing the
> protocol and I expect most packages that need this functionality will be
> external tree packages (we need it for vendor supplied binaries for which
> sources are not available).

 So no testing. Oh well.

 Regards,
 Arnout


More information about the buildroot mailing list