Hi Quentin, On Mon, 20 Feb 2023 at 04:15, Quentin Schulz <quentin.sch...@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.sch...@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 <tr...@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 <tr...@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 <tr...@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
