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

[Simon Glass]

Hi Quentin,

On Mon, 20 Feb 2023 at 04:15, Quentin Schulz
<quentin.schulz at theobroma-systems.com> wrote:
>
> 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 at 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 at 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 at 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 at 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.

OK, but why do you want to use the build directory at all? It seems
like a hassle to set up. With the series I sent it is automatic and
all that is needed is to add ~/.binman-tools to your path.

Regards,
Simon

Applied to u-boot-dm/next, thanks!