Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: James Hilliard <james.hilliard1@gmail.com>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 14/16] package/pkg-cargo: add support for unlocked packages
Date: Mon, 3 Jun 2024 13:52:36 +0200	[thread overview]
Message-ID: <Zl2uhKujEDzv2Gur@landeda> (raw)
In-Reply-To: <CADvTj4rhK6KUZ-q-w65ZDGJZyh2fs2DnHXM-mxzMv3LS9GOQYA@mail.gmail.com>

James, All,

On 2024-06-02 15:25 -0600, James Hilliard spake thusly:
> On Sun, Jun 2, 2024 at 3:15 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > On 2024-06-02 14:53 -0600, James Hilliard spake thusly:
> > > On Sun, Jun 2, 2024 at 2:42 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
[--SNIP--]
> > > > +When a package source tree contains a +Cargo.lock+ file, the package has
> > > > +been _locked_: cargo did store the versions for the complete dependency
> > > > +chain in the +Cargo.lock+ file; that is then reused by cargo during the
> > > > +vendoring, which yields a reproducible dependency chain, and thus a
> > > > +reproducible tarball; therefore, it is possible to compute a hash for
> > > > +that archive. If a package was however not locked, then the versions for
> > > > +the dependencies are unknown, the dependency chain is not reproducible,
> > > > +and the archive is then not reproducible, which implies there can be no
> > > > +hash for that archive.
> > > Hmm, for these cases shouldn't we generate and commit the lockfile to
> > > the buildroot package so that we can then generate a deterministic archive
> > > and archive hash?
[--SNIP--]
> Yeah, something along those lines, one thing that might be a bit tricky is
> that we probably need to incorporate the Cargo.lock file hash or something
> like that in the archive name, so that way if the Cargo.lock file needs to be
> regenerated the archive name will also be appropriately changed at the same
> time.

Hmmm... Indeed, this would cause quite some grief if we would change the
Cargo.lock...

However, I don't see an easy solution to this issue... :-/

Well, I do have an idea, and it would definitely work, but it would be
*excessively* ugly... I'll try to implement it, but as an additional
change on-top of the existing series, because I am not sure it would br
meaningful in the end... Let's see...

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

  reply	other threads:[~2024-06-03 11:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02 20:39 [Buildroot] [PATCH 00/16] support/download: allow downloading unlocked cargo packages (branch yem/cargo-unchained) Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 01/16] package/pkg-download: symplify calling parameters Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 02/16] package/pkg-generic: split long, unreadable DOWNLOAD line Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 03/16] utils/check-package: add option to run the test-suite Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 04/16] utils/checkpackagelib: instruct shellcheck to follow included files Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 05/16] support/download/dl-wrapper: fix shellcheck errors Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 06/16] support/download/cargo-post-process: fix shellcheck Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 07/16] support/download: pass post-process options to post-process helper Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 08/16] support/download: accept manifest path as a post-process option Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 09/16] pakcage/pkg-cargo: use post-process opts to pass manifest path Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 10/16] package/pkg-python: use post-process opts to pass Cargo " Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 11/16] package/python-bcrypt: " Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 12/16] support/download: no longer support BR_CARGO_MANIFEST_PATH in cargo post-process Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 13/16] docs/manual: rephrase end of vendoring section Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 14/16] package/pkg-cargo: add support for unlocked packages Yann E. MORIN
2024-06-02 20:53   ` James Hilliard
2024-06-02 21:15     ` Yann E. MORIN
2024-06-02 21:25       ` James Hilliard
2024-06-03 11:52         ` Yann E. MORIN [this message]
2024-06-03 17:48           ` James Hilliard
2024-06-03 18:43             ` Yann E. MORIN
2024-06-03 18:55               ` James Hilliard
2024-06-03 19:45                 ` Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 15/16] utils/checkpackagelib: add test for default _CARGO_LOCKED Yann E. MORIN
2024-06-02 20:39 ` [Buildroot] [PATCH 16/16] RFC: package/anvil: new package Yann E. MORIN

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=Zl2uhKujEDzv2Gur@landeda \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=james.hilliard1@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox