Re: [Buildroot] [PATCH] package/pkg-download: do not try to vendor _EXTRA_DOWNLOADS

[<yann.morin@orange.com>]

Arnout, All,

On 2022-05-10 21:24 +0200, Arnout Vandecappelle spake thusly:
> On 06/05/2022 07:21, yann.morin@orange.com wrote:
> >On 2022-05-05 22:37 +0200, Arnout Vandecappelle spake thusly:
[--SNIP--]
> >>  Applied to master, thanks, with a few changes:
> >>      - no loop needed for MAIN_DOWNLOAD, it can have only one;
> >In fact, that was on purpose: it can have no main download...
> >Indeed, a package can very well only declare extra downloads...
> >I forgot to explain that in the commit log, sorry.
>  OK. However, somehow this seems to work:

Yes, otherwise we could not even install host-skeleton to begin with....

>  So I don't think it is needed after all?

Still, I am not happy that we are in a situation that works by accident.
I'd much prefer we understand why exactly this does not break...

> The dl-wrapper script apparently
> doesn't do anything if the filename is empty.

It really works by accident:

 1. we pass no URI, so I thought the dlwrapper would fail, as it
    basically does:

        download_and_check=0
        for uri in "${uris[@]}"; do
            ...
        done
        if [ "${download_and_check}" -eq 0 ]; then
            exit 1
        fi

    However, it does not even go that far...

 2. even though there is no output file, we still pass the path to
    the package output directory as the output path. So, as part of
    validating the download, the wrapper checks if the output file
    exists, and checks its hash:

        if [ -e "${output}" ]; then
            if support/download/check-hash ${quiet} "${hfile}" "${output}" ...
                exit 0
            ...
        fi

 3. the output path does exist now, because we explicitly create it just
    before calling the wrapper, because that's where we also locate the
    lockfile.

So, this is all a bit fragile, and I am not feeling very happy about
that...

So, I'll cook up a fixup patch to revert to the previous behaviour of
not even attempting a download in that case.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
| +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
|      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot