dev-master no longer works in main branch (it does in 2.x)

[Pin0]

Describe the bug
when updating a dependency using "composer update vendor/packagename" and in the composer json the require is like this:

 "repositories": {
       {
            "type": "composer",
            "url": "https://packagist.vendor.tld"
        }
    },
"require": {
        "vendor/packagename": "dev-master"
    }

the dependency is not updated

To Reproduce
Provide configuration file(s) and the exact command that you invoked.

php satis/bin/satis build satis.json public/
the public is hosted on https://packagist.vendor.tld

satis.json

{
    "name": "vendor/packagist",
    "homepage": "https://packagist.vendor.tld",
    "repositories": [
        	{ "type": "vcs", "url": "https://code.vendor.tld/git/packagename.git" }
    ],
    "require-all": true
}

Outcome
no errors, works as it always did.

Expected behavior
The latest version of vendor/packagename is retrieved when using "composer update vendor/packagename"

Additional context
This bug happens on the main branch, if we use branch 2.x it works perfect :)

We think it has something todo with the composer 2 dependencies that are updated but other then that we are in the dark...

[alcohol]

Cannot reproduce.

[enfoqueNativo]

@alcohol Hi, i think he referring to something like this:

Example composer.json:

{
    "name": "my/project",
    "type": "project",
    "description": "Hello World",
    "version": "1.0.0",
    "repositories": {
        "satis": {
            "type": "composer",
            "url": "Your satis installation url"
        }
    },
    "require": {
        "php": ">=7.3",
        "ioncube/php-openssl-cryptor": "dev-master"
    },    
    "minimum-stability": "dev",
    "prefer-stable": true
}

With your satis installation (main branch) indexing ioncube/php-openssl-cryptor the following happens:

• Composer 2.x can perform composer install & composer update without troubles
• Composer 1.x fails with following message

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package ioncube/php-openssl-cryptor dev-master exists as ioncube/php-openssl-cryptor[dev-master] but these are rejected by your constraint.

@Pin0 Am i getting it wrong?

[SvenRtbg]

Jordi Boggiano has described the new behaviour of Composer 2 vs Composer 1 in the blog https://blog.packagist.com/deprecating-composer-1-support/

Essentially: Any package will only ever be available for Composer 1 once a request for it from a Composer 2 instance has been received. This is to reduce the amount of monolithic meta data that is required for Composer 1.

It may be a side effect of what you are experiencing

[enfoqueNativo]

@SvenRtbg Thanks for the info, didn't know about it... anyway maybe i've just misunderstood @Pin0

[Pin0]

@SvenRtbg and @enfoqueNativo I think that is correct. We resolved it by not using dev-master and we should use composer 2 anyway

[aimeos]

The problem seems that Satis 3.x generates two files which contains the available packages, one for the tagged releases and one for the dev versions:

<vendor>/p2/<vendor>/<package>.json // only tagged releases
<vendor>/p2/<vendor>/<package>~dev.json // only dev versions

composer (2.x) does only load the <package>.json file, not the <package~dev.json file and thus, doesn't know that the dev versions exist.

[SvenRtbg]

Satis isn't tagged anymore, and the last tag was 1.0.0, so referring to "Satis 3.x" is not describing what version you are using. The difference between the repo format of Composer 1 and 2 is exactly what you are describing, but I doubt Composer 2 is ignoring the dev file all the time.

[aimeos]

The exact used Satis version is 3.0.x-dev (therefore, referred as 3.x).

The problem was that the web server denied access to <package>~dev.json files due to the tilde in the file name. After fixing the web server configuration, downloading -dev versions works as expected.