Re: [Buildroot] [PATCH 5/6] package/python-pydantic-core: bump for fixes with python 3.12

["Yann E. MORIN" <yann.morin.1998@free.fr>]

James, All,

On 2024-06-14 12:03 -0600, James Hilliard spake thusly:
> On Fri, Jun 14, 2024 at 11:33 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2024-06-14 18:21 +0200, Yann E. MORIN spake thusly:
> > > The package is not yet available on PyPI, so go fetch it at the source.
> > And even though it now is on PyPI, I am still of the opinion that, when
> > the official upstream repo is usable as-is, it is better to use the
> > sources from there than from the package on PyPI, for which we have no
> > way to know how it has been generated. We should only rely on fetching
> > from PyPI thos packages for which the upstream sources are not enough
> > (e.g. needs heavy tooling that we lack).
> 
> I'm not sure why it would make sense to prefer git sources for PyPi
> packages when we prefer release tarballs for non-PyPi packages

For git-hosted packages where there is the possibility to use a remotely
generated tarball, I still think (and always said so) that it was an
error to do so. Indeed, we have already had at least three known cases
where the remote forge actually changed the way the archives were
generated, and _that_ broke our hashes (as well as everybody elese's);
and we are at the mercy of such changes in the future. Even if a forge
does not change its tarball generation mechanism, it is still possible
that archvie generated by git change; one such case is when a repository
ahs a file has the git attribute export-subst and uses the %h
(abbreviated commit hash) placeholder, where git may decide to increase
the length of the short hash to avoid collision when the repository
grows...

Instead, we should have always used git-clone and rely on our archive
helpers. True that we did change them, and that we had to introduce
archvie format versions, but for a given version of Buildroot, it was
perfectly stable.

> as
> PyPi sdist tarballs are effectively release tarballs.

Except when they are not, beause they still need to be vendored when
they have rust code in there. But that's not the actual issue I have...

Some have also had various mangling done, and thus one has no idea how
the official source repository can be used to generate the "sdist" and
then you might get in legal trouble because what you believe is source
is actually not source but generated code for whihch the actual source
is not avaialble, and then you might get in breach of the license when
you distribute that...

That is also true for other tarballs, as you mention, but this is much
less often the case; the only release tarball for an autotools package
that I remember of, that had such an issue, were a few binutils versions
were they included a generated file without its source, and that was an
oversight, not done on purpose, and they fixed it (that caused quite a
mess)...

> One advantage to using PyPi releases is you avoid issues with hash's
> changing due.

When we change our download helpers, we are responsible for the change
in hashes, so we can plan for it. As I said above, for a given version
of Buildroot, then archives are reproducible; it's only when _we_ decide
to change our helpers that we have to update the hashes. AFAICS, ther
eis nothing that would prevent a packager to push an updated archive to
replace an existing one on PyPI, thus actually breaking the hash without
any resort on our side to wokrkaround that.

As I said earlier, the only case where it would be an acceptble
last-resort, would be when the archive on PyPI contains _additional_
data that was generated with heavy tooling that we lack (and can't
easily package in Buildroot).

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot