All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: buildroot@buildroot.org, Thomas Perale <thomas.perale@mind.be>,
	 Ricardo Martincoski <ricardo.martincoski@datacom.com.br>
Subject: Re: [Buildroot] [PATCH v3 2/3] package/pkg-python: derive PyPI site from blake2b-256 hash
Date: Wed, 16 Sep 2026 14:46:28 +0200	[thread overview]
Message-ID: <aqpraYAviEpbIuPJ@windsurf> (raw)
In-Reply-To: <CADvTj4qjk_fMqf4M8Mq4C=w34GuL4e8uYBFsUSx2grCC2Dukdw@mail.gmail.com>

Hello,

On Tue, Sep 15, 2026 at 11:14:14AM -0600, James Hilliard wrote:

> > I must say I am not a fan of this approach. It is very "tricky" and
> > not obvious to understand that the _SITE information is in some cases
> > derived from information in the .hash file. For me this breaks the
> > principle of "obviousness" that makes Buildroot generally quite nice
> > to work with. I don't really find the current situation problematic,
> > and what we have currently is completely obvious to use/understand.
> 
> Yeah, it's a bit weird deriving from a non-make file, although auto deriving
> _SITE in general does have precedent and if the hash is missing there
> should at least be a clear error explaining the reason:
> https://github.com/buildroot/buildroot/blob/2026.08/package/pkg-luarocks.mk#L79-L85

This is not at all the same thing: this is a case where we have a
default. If nothing is specified, a default is used, but that default
value is not magically inferred from the .hash file.

> > Of course, if the other maintainers are happy with your approach, I
> > will not oppose. But since so far nobody provided feedback, I thought
> > I should share my humble feedback.
> 
> Here's some background on where the suggestion for this change came from:
> https://lore.kernel.org/buildroot/fb186248-7df4-4f73-94a2-c9b2ebefa843@bubu1.eu/

OK. I still find this "meh". But again, this is just my own
opinion/voice, and I will not oppose to this getting merged. It's just
that it's been sitting on patchwork for a bit of time with no
feedback, so I thought that to help get things move forward, I would
share my feedback.

> > Another concern: I assume you're adding
> > $(BR2_COREUTILS_HOST_DEPENDENCY) to DOWNLOAD_DEPENDENCIES so that
> > 'awk' is available?
> 
> Isn't awk already mandatory?:
> https://github.com/buildroot/buildroot/blob/2026.08/support/dependencies/dependencies.sh#L157

Indeed. But then why does your patch have:

  $(2)_DOWNLOAD_DEPENDENCIES += $(BR2_COREUTILS_HOST_DEPENDENCY)

> > But then if we run "make show-info" without doing
> > any build, it means we no longer have the _SITE information?
> 
> That should still work fine, we still set _SITE with this approach, it only
> changes how/where it gets set.

Not if $(BR2_COREUTILS_HOST_DEPENDENCY) must be built to calculate the
_SITE value (see above question).

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2026-09-16 12:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18  6:51 [Buildroot] [PATCH v3 1/3] support/download: add blake2b-256 hash support James Hilliard
2026-06-18  6:51 ` [Buildroot] [PATCH v3 2/3] package/pkg-python: derive PyPI site from blake2b-256 hash James Hilliard
2026-09-14 21:22   ` Thomas Petazzoni via buildroot
2026-09-15 17:14     ` James Hilliard
2026-09-16 12:46       ` Thomas Petazzoni via buildroot [this message]
2026-09-16 16:56         ` James Hilliard
2026-09-16 20:38           ` Thomas Petazzoni via buildroot
2026-06-18  6:51 ` [Buildroot] [PATCH v3 3/3] package/python-async-timeout: use hash-based PyPI site James Hilliard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aqpraYAviEpbIuPJ@windsurf \
    --to=buildroot@buildroot.org \
    --cc=james.hilliard1@gmail.com \
    --cc=ricardo.martincoski@datacom.com.br \
    --cc=thomas.perale@mind.be \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.