[Buildroot] [PATCH v3 2/5] package: add generic support for lz archives
Yann E. MORIN
yann.morin.1998 at free.fr
Fri Feb 17 17:07:22 UTC 2017
Arnout, All,
On 2017-02-17 08:43 +0100, Arnout Vandecappelle spake thusly:
> On 16-02-17 23:11, Yann E. MORIN wrote:
> > Peter, All,
> >
> > On 2017-02-16 23:03 +0100, Peter Korsgaard spake thusly:
> >>>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
> >> > Actually, there is a use-case for being able to specify some of those,
> >> > at least the downloaders: git, wget, svn, scp...
> >>
> >> > I use a script that is called in lieue of each downloader:
> >>
> >> > BR2_WGET="/path/to/wrapper wget --passive-ftp -nd -t 3"
> >> > BR2_GIT="/path/to/wrapper git"
> >> > and so on...
> >>
> >> > That script is responsible for memorising, for each package, whether it
> >> > was downloaded from the primary mirror, the official site, or the backup
> >> > mirror, then acts according to where the package was downloaded:
> > [--SNIP--]
> >> Nice, but presumably you could also simply create a directory with
> >> wget/git/svn/.. symlinks to your wrapper and prepend that to your path
> >> before running buildroot, and then change the wrapper to do its stuff
> >> and call further in the path for the real tool, similar to the recently
> >> added date wrapper for reproducable builds?
> >
> > Indeed, that would be doable, if a little bit more involved in the
> > wrapper. But not something overly complex either.
> >
> > So, overriding the downloaders is in fact not strictly required.
>
> Actually, for the downloaders there *are* useful options to override, e.g.
> proxies, authentication, certificate stores, ... The configuration variables are
> not the most convenient way to use those (especially since you may need to use
> different options for different packages, e.g. internal vs. external),
Besides, options valid in a location may well be invalid in another. For
example, proxies can be different, even in an enterprise network (i.e.
location- or destination-based proxies). So those should be in the
environment of the user doing the build, not in the configuration.
Sme goes for the certificate stores (just to re-use your examples): an
enterprise proxy could well be an MITM proxy, so would need its certs to
be used. Or as you said, an internal server may require a set of certs
and another server another set, so that would need different options
per-package. Which we already offer, by the way...
> but it's
> the only thing we have now. Apart from wrapper scripts, of course.
I come to believe that using wrappers in those conditions is the best
answer we can suggest.
IMHO, setting site-local options in the config is toxic.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list