Upgrading from satis 1.0.0 - Shasum mismatch

[kimmenbert]

Hi,

We're trying to upgrade satis from 1.0.0 to latest version. To get rid of old junk and get a fresh start we setup a new installation and migrated stuff over.

We're now stuck with a lot of projects using packages from the old satis, that gets a mismatching shasum when trying to install trough the new installation of satis.

It's too many projects to go trough and fix this. Is there any way we could upgrade satis without loosing the old shasum, or any other way around this issue?

Thanks

[alcohol]

we setup a new installation and migrated stuff over

What does that mean? Can you be more specific?

a mismatching shasum when trying to install

Not sure I understand. Why would the shasum not match?

[kimmenbert]

To keep the old version running while upgrading satis, we created a new satis installation from scratch on a new server.

Might be an overstatement to call it migrating, we have a script that generates satis.json based on bitbucket repositories in specific bitbucket projects. Meaning, we migrated that script over and ran it to generate a satis.json like the one we have on the old satis installation.

The mismatching shasum I guess is because of this: #516 (comment)

[SvenRtbg]

I can confirm that sometimes (haven't investigated further, but your comment finding would explain it) the hashes change. For that reason I opted for not deleting ZIP files that were created. This is accumulating waste, and you'll end up with the "wrong" hash versions again and again after updates if some developer has this wrong version in his cache. But on the other hand, composer will happily install anything provided that the URL is still available. So even though no meta data is pointing to it, old pointers will not break your application.

This is no answer to what to do about it, but it is less bad that you might fear.

I can assume that it would be really hard to create consistent, non-changing hashes inside Satis/Composer, depending on which info is pulled to create them.

[kimmenbert]

Thanks for quick responses. I feared that there would be no real solution to this, and was thinking about what would happen if I migrated the old zips over, will give it a shot. Then I guess we will have to allow our deployment pipelines to connect to bitbucket to download when shasum mismatch is found (currently it fails because of missing auth to bitbucket). And this will in the future be solved after updates in the different projects.

I'll keep this open in case someone has some magic solution, feel free to close it if you want.

[alcohol]

I'll leave this open and mark it as a bug for now since the behavior is unclear / unpredictable.

[sirbarrence]

I just had this problem when attempting to upgrade from statis at rev e2f8b9a (April 2017) to satis at rev 6729f87 (Oct 2021). For a certain package, I found that while the size and the unpacked contents of the old and new tar files for a given revision were identical according to diff, the order of the files in the tar files were different according to tar -t. When I run tar -tf old-satis-docroot/dist/some-package-hash.tar and tar -tf new-satis-docroot/dist/some-package-hash.tar, the file listings contain the same files, but they are in a different order. The old listing seems to be in case-sensitive alphabetical order. The new listing is in some order I cannot identify. The files are functionally the same once unpacked, but it appears composer uses the tar files to compute the sha1 hash, not the unpacked contents of the tar files.

I'm not sure what to do about this besides regenerate all my lock files across multiple repos and maintenance branches.

[Antik9421]

Simple add settings
"archive": { "directory": "archives", "format": "tar", "skip-dev": true, "checksum": false }
and repair in old build composer.lock delete shasum keys