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 20:43:11 +0200	[thread overview]
Message-ID: <Zl4Ov3hQoTGFl6e8@landeda> (raw)
In-Reply-To: <CADvTj4qyfvGUCbfMj=uWSxcJkBH7LBs-hcdv4Z3_Ax6FtYTnNg@mail.gmail.com>

James, All,

On 2024-06-03 11:48 -0600, James Hilliard spake thusly:
> On Mon, Jun 3, 2024 at 5:52 AM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > 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...
> Probably it would be good enough to say take the first 7 characters of the
> sha256 hash(same length as a git shorthash) of the Cargo.lock file and
> incorporate that into the archive filename appended to the package version.

The problem with short hashes, is that they are much less unique than
full hashes. We've excluded using short hashes wherever we had the
choice (see for example the recent git export-subst attribute, where we
replace the short-hash placeholder with the full-length hash). So I
would refrain from using a short-hash anywhere else as well.

There is a simpler solution, though, which is to rely on the .mk to set
the version and be done with it:

 1. it is very seldom that a cargo package is not locked, so we don't
    need anything too complex;
 2. for unlocked packages, we'll very seldom update our Cargo.lock, so
    we don't need anything too fancy;
 3. if one forgets to update the version when updating Cargo.lock,
    there will be a hash mismatch on download anyway, so we'll notice.

So that's what I've gone with. It requires a few tricks and tweaks here
and there, but this is already working since a few hours ago, but I got
distracted and did not have time to finish the work (and the commit
logs); maybe later tonight, or tomorrow...

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 18:43 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
2024-06-03 17:48           ` James Hilliard
2024-06-03 18:43             ` Yann E. MORIN [this message]
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=Zl4Ov3hQoTGFl6e8@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