Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 783372 - cargo.eclass: cargo_src_unpack also unpack file that is not a cargo crate
Summary: cargo.eclass: cargo_src_unpack also unpack file that is not a cargo crate
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Rust Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-04-17 07:31 UTC by 12101111
Modified: 2021-04-19 04:11 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description 12101111 2021-04-17 07:31:00 UTC
In cargo.eclass:

cargo_src_unpack() {
    ...
    for archive in ${A}; do
        case "${archive}" in
            *.crate)
                  ...
            cargo-snapshot*)
                  ...
            *)
                unpack ${archive}
                ;;
        esac
   done
   ...
}

Sometime I want unpack those file manually to other directory.

Reproducible: Always
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-04-18 02:12:53 UTC
This might be problematic given it's exported as a phase?
Comment 2 Georgy Yakovlev archtester gentoo-dev 2021-04-18 02:55:54 UTC
removing or modifying it will break a lot of things, so it'll remain default behavior.

I suggest just removing auto-unpacked stuff and unpacking again with a custom path, using unpack() call.

other solution I see is separating *.cargo unpacker as a standalone function(s), so people can do

src_unpack() {
 unpack_crates # searches only for *.crate in ${A}
 unpack whatever anywhere
 cargo_gen_config
}

and cargo_src_unpack can call it.
Comment 3 12101111 2021-04-19 04:11:33 UTC
My original issue is a tarball don't have a root directory, unpack it directly will put every file into ${WORKDIR}. 
But later I found that tarball, https://chromium.googlesource.com/chromium/src/third_party/zlib/+archive/e84c9a3fd75fdc39055b7ae27d6ec508e50bd39e.tar.gz don't have a stable checksum.
It seems go-module.eclass have the same behavior, so just remain this behavior in cargo.eclass. I will use git submodule instead.