Re: [PATCH] cargo.eclass: separates crate unpacking logic in cargo_src_unpack into a separate function

On 8/12/26 8:58 AM, Jaco Kroon wrote:
> Hi All,
> 
> This raises a related point.  What if an eclass could do something like
> registering extensions it can handle unpacking for?
> 
> Say in cargo eclass during pkg_setup phase function:
> 
> register_unpack_function crate _cargo_unpack_crate
> 
> Then the default src_unpack would handle things entirely, it could even
> be possible for ebuilds to register it's own custom unpacks if it only
> needs to have special handling for some specific subset of SRC_URIs.
> 
> This should also more cleanly handle possible future cases, amongst
> others like what Ingenarel has mentioned.
> 
> Just an idea.  Perhaps for future EAPI.  Just not sure how easy it would
> be to handle the parallel crates unpack in that methodology, nor if
> parallel unpack would benefit other packages too, and if unpack has
> dependency ordering in unpacking if that could be a problem.


https://bugs.gentoo.org/516014


-- 
Eli Schwartz

-----BEGIN PGP SIGNATURE-----

wnsEABYIACMWIQTnFNnmK0TPZHnXm3qEp9ErcA0vVwUCanxzNwUDAAAAAAAKCRCEp9ErcA0vV2Q5
AP9w4VjNbz3gIhLDZiOdrLa8aWpm5NJurj4fXwUrEdmuTQEA5xyVLTmLCK+IWz94E/GXIQ4gB0dD
GiDHgQRJIoAM2wA=
=c2br
-----END PGP SIGNATURE-----