Re: [PATCH] binman: Avoid requiring a home directory on startup

[Quentin Schulz <quentin.schulz@theobroma-systems.com>]

Hi Simon,

On 2/18/23 00:49, Simon Glass wrote:
> Hi Quentin,
> 
> On Fri, 17 Feb 2023 at 05:21, Quentin Schulz
> <quentin.schulz@theobroma-systems.com> wrote:
>>
>> Hi all,
>>
>> On 2/17/23 03:55, Simon Glass wrote:
>>> Hi Tom,
>>>
>>> On Thu, 16 Feb 2023 at 17:19, Tom Rini <trini@konsulko.com> wrote:
>>>>
>>>> On Thu, Feb 16, 2023 at 05:12:33PM -0700, Simon Glass wrote:
>>>>> Hi Tom,
>>>>>
>>>>> On Tue, 14 Feb 2023 at 13:27, Tom Rini <trini@konsulko.com> wrote:
>>>>>>
>>>>>> On Tue, Feb 14, 2023 at 03:12:46PM -0500, Mike Frysinger wrote:
>>>>>>> On Tue, Feb 14, 2023 at 3:08 PM Tom Rini <trini@konsulko.com> wrote:
>>>>>>>> Downloading things from the internet and putting them in to the default
>>>>>>>> PATH always and forever is also kinda not great?
>>>>>>>
>>>>>>> you just described a standard distribution.  this is like literally
>>>>>>> how all of them work.  not to mention every other language-specific
>>>>>>> distro tool out there (e.g. Python pip, Perl cpan, Go, etc...).
>>>>>>>
>>>>>>> maybe you'd like more guarantees on top (e.g. signature verification)
>>>>>>> which is reasonable.
>>>>>>>
>>>>>>> but to be clear, this script is already merged & in the tree, so your
>>>>>>> feedback doesn't block this patch.
>>>>>>
>>>>>> Yes, exactly. This is a fix on top of what we do today, so it should go
>>>>>> in. But modern distributions only install signed packages, and
>>>>>> language-specific tools tend to be a hive of bad examples. Looking over
>>>>>> binman right now, I see that we're either using apt (and oh, there's
>>>>>> "aot" typo in one spot) or downloading from a known Google drive, for
>>>>>> only a few less common tools.
>>>>>>
>>>>>> So yes, I would like to see some ideas on how to improve things in the
>>>>>> future so we aren't putting the binaries somewhere that's not a default
>>>>>> (or frequently common) PATH location.
>>>>>
>>>>> Are you thinking they should go in ~/.binman-tools or something like
>>>>> that? Then we would need to tell people to add it to their path. But
>>>>> we could make binman look there automatically.
>>>>
>>>> We should document that it's where we're putting stuff, not so much
>>>> "tell" them, unless you mean as a note when downloading.  But yes,
>>>> ~/.binman-tools sounds reasonable.  Maybe a flag to point elsewhere?
>>>
>>> OK I will take a look.
>>>
>>
>> I think this should be directly put into the output/build directory used
>> by U-Boot, because what happens when you have two U-Boot git repos with
>> different version requirements for those host tools? Then you need to
>> make sure you're not building both at the same time, that you update
>> them properly before each build, etc.
> 
> My advice: *Don't do that*
> 
> So far as binman is concerned, a tool is a tool. Tools should be
> backwards compatible so updating to the new one should fix all the
> problems.
> 

That's a very bold claim :)

> The problem with using the output dir is we then have to download them
> for each build, or cache them somewhere. To my mind, the 'binman tool'
> feature is a convenience to reduce the pain involved in obtaining
> tools needed to build. It is a not a panacea for strange situations.
> 

Have the default in the build directory and allow the user to define an 
out-of-tree directory if they want to cache them somewhere? Similar to 
Yocto with SSTATE_DIR/DL_DIR, Buildroot with BR2_DL_DIR for example.

Cheers,
Quentin