[Buildroot] [PATCH] package/pkg-generic: explicitly do not download package withtout source

* [Buildroot] [PATCH] package/pkg-generic: explicitly do not download package withtout source
@ 2022-05-11  6:23 yann.morin
  2022-05-11 17:15 ` Arnout Vandecappelle
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: yann.morin @ 2022-05-11  6:23 UTC (permalink / raw)
  To: buildroot; +Cc: Yann E. MORIN

From: "Yann E. MORIN" <yann.morin@orange.com>

Recent commit f0c7cb01a960 (package/pkg-download: do not try to vendor
_EXTRA_DOWNLOADS) got last-minute changes when applied, which changed
the expected behaviour for packages that do not have a main download.

Before f0c7cb01a960, the dl-wrapper would not even be called for those
packages, and the original patch that was sent also avoided downloading
such packages, but f0c7cb01a960 now causes the dl-wrapper to be called.

It is however an accident that the dl-wrapper does not fail. Indeed, it
is expected to fail if no download was successful; we pass no URI, so
the dl-wrapper should have failed, 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...

Even though there is no output file, we still pass the path to the
package output directory as the output path. So, to avoid downloading
files already present, 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

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 it ends up trying to validate the hash of a directory, but it fails
to, as there is indeed no hash file for that package. And a missing hash
file is just a warning, not an error, which makes the download actually
a success...

So, this is currently working, and this is by pure luck.

However, there is a potential issue: if a target package is a virtual
package, but the host package is a real package, e.g. the same foo.mk
does (or the other way around):

    HOST_FOO_VERSION = 1.2.3
    HOST_FOO_SITE = http://example.net/
    $(eval $(virtual-package))
    $(eval $(host-generic-package))

If there is a hash file to validate the host download, then the current
situation will cause a failure, because there would be a hash file, but
no hash for the output path of the target variant, which would then be
a hard-error.

So, revert to the behaviour from before f0c7cb01a960, where no download
is attempted for a package without a source (really, without a main
download, now).

Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
---
 package/pkg-generic.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/pkg-generic.mk b/package/pkg-generic.mk
index 38219ce088..b233b07548 100644
--- a/package/pkg-generic.mk
+++ b/package/pkg-generic.mk
@@ -192,7 +192,7 @@ $(BUILD_DIR)/%/.stamp_downloaded:
 			break ; \
 		fi ; \
 	done
-	$(call DOWNLOAD,$($(PKG)_MAIN_DOWNLOAD),$(PKG),$(patsubst %,-p '%',$($(PKG)_DOWNLOAD_POST_PROCESS)))
+	$(if $($(PKG)_MAIN_DOWNLOAD),$(call DOWNLOAD,$($(PKG)_MAIN_DOWNLOAD),$(PKG),$(patsubst %,-p '%',$($(PKG)_DOWNLOAD_POST_PROCESS))))
 	$(foreach p,$($(PKG)_ADDITIONAL_DOWNLOADS),$(call DOWNLOAD,$(p),$(PKG))$(sep))
 	$(foreach hook,$($(PKG)_POST_DOWNLOAD_HOOKS),$(call $(hook))$(sep))
 	$(Q)mkdir -p $(@D)
-- 
2.25.1


_________________________________________________________________________________________________________________________

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

^ permalink raw reply related	[flat|nested] 7+ messages in thread