Re: [Buildroot] [PATCH] package/pkg-cargo: don't install crates tracking

[Thomas Petazzoni via buildroot <buildroot@buildroot.org>]

Hello,

On Wed,  4 Sep 2024 22:42:34 +0200
"Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

> By default, 'cargo install' also installs a kind of "registry" in
> /usr/.crates2.json and /usr/.crates.toml [0]:
>     To track information of installed executables, some extra files,
>     such as .crates.toml and .crates2.json, are also created under this
>     root.
> 
> Presumably, this would be used by "cargo uninstall" to properly cleanup
> the package [1]:
>     By default all binaries are removed for a crate [...].
> 
> However, in the context of Buildroot, this is useless, as we do not
> uninstall packages, and thus those files are superfluous.
> 
> Tell cargo to not create that tracking information, by using --no-track
> to "cargo install".
> 
> Note that this would cause cargo to fail to install a file that already
> exists [2], like would be the case when running foo-reinstall for example:
>     --no-track
>     By default, Cargo keeps track of the installed packages with a
>     metadata file stored in the installation root directory. This flag
>     tells Cargo not to use or create that file. With this flag, Cargo
>     will refuse to overwrite any existing files unless the --force flag
>     is used. This also disables Cargo’s ability to protect against
>     multiple concurrent invocations of Cargo installing at the same
>     time.
> 
> However, we do already use --force which allows cargo to overwrite
> existing files without any further ado, so in our case, --no-track will
> only disable the tracking information.
> 
> Also, in Buildroot, we do not have concurrent installation _to the same
> location_: either PPD is disabled, in which case only one package will
> be installed to the common target/ at a time, or we're using PPD, so
> each package will get installed into its own target/. Thus, --no-track
> has no adverse side effect for us.
> 
> Closes: #17

Thanks for the patch, which I have applied to next. However, I would
really like:

Closes: #17

to be:

Fixes:

  https://gitlab.com/buildroot.org/buildroot/-/issues/17

For two reasons:

(1) For autobuilder failures we use a full URL, not just the
    identifier, so we should do the same for Gitlab issue. It also makes
    them directly clickable from the commit log, which is really nice,
    and makes it very clear that it's fixing a Gitlab issue

(2) Fixes: gets picked up by patchwork and not Closes:

I adjusted this when committing, so this was really just to hopefully
establish what we consider to be our best practice on this matter :-)

Thanks a lot for addressing this issue!

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