Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoHash parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoHash parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoHash parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Taking a cargoSha256 parameter isn't a good idea, because it will
produce a silently broken FOD if we change the hashing scheme, like
we're doing here. Overlays should provide a full cargoDeps object,
which wouldn't have that problem, because the overlay would be
responsible for the whole FOD.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
Cargo 1.84.0 seems to have changed the output format of cargo vendor
again, once again invalidating fetchCargoTarball FOD hashes. It's
time to fix this once and for all, switching across the board to
fetchCargoVendor, which is not dependent on cargo vendor's output
format.
