Hi,

While packaging php-guzzlehttp-message-integrity-subscriber (as needed
by aws-sdk-for-php 3), the following warning was displayed:

OR-ed versions are not supported require:guzzlehttp/guzzle (~4.0|~5.0)

While the current default is safe in my use case (no version at all is
introduced in the Debian control file), it would have been nice if this
	(>= 4.0, < 5~~) or (>= 5.0, < 6~~)
would have been translated as
	(>= 4.0, < 6~~)
in such case (i.e., when the OR-ed versions can be summed up).

Regards

David

P.-S.: again pilling up a request, will hopefully be able to provide a
patch for it when I’ll have some time to dive in the code.

Please fix this issue some time soon. It causes problems with
each new upgrade of things like Symfony because the other packages
have debian/patches/ like this one…

$ cat debian/patches/pkg-php-tools-deficiency-workaround.diff
# DP: or’d dependencies are not supported (#765899)
# DP: choose the branch currently shipped in Debian
--- a/composer.json
+++ b/composer.json
@@ -22,7 +22,7 @@
     ],
     "require": {
         "php": ">=5.3.9",
-        "symfony/translation": "~2.6 || ~3.0 || ~4.0"
+        "symfony/translation": "~3.0"
     },
     "require-dev": {
         "friendsofphp/php-cs-fixer": "~2",


If pkg-php-tools would generate sensible dependencies, this would
not be necessary, and we’d not have the trouble of being specific
to a release of Symfony (and needing to change the patch in back‐
ports).

Hi Thorsen,

Le 19/11/2019 à 15:55, Thorsten Glaser a écrit :

I believe the patch is wrong. Why patch at all?

A proper way to actually express the current dependency wound be :

+        "symfony/translation": "<5"

And, eventually, also

+        "symfony/translation": "> 2.6"

Since Stretch shipped with 2.8, the latter is probably overkill. Since I
expect bullseye to ship with 4.4 [1], even the former is probably
overkill for your needs. So just leaving things as they are will do the
right thing here: no versioned dependency at all.

[1] I don’t believe symfony will be upgraded to 5 in bullseye (according
to the current [roadmap], I believe the next 5.4 LTS release will happen
by the end of 2022, and I expect the freeze to happen sooner.

	roadmap: https://symfony.com/releases

Regards

David

David Prévot dixit:

You answer this yourself:

But the package relationships should be correct to ease
the upgrade process, that is, ± 1 distribution release
at least. There’s also downstreams to consider, so having
the *correct* version used is certainly sensible.

Perhaps, but this is not the only case of OR dependencies
in the tangled mass of PHP libraries we’ve seen during
packaging of Movim. This means any reasoning based on any
specific example (and/or distribution release) necessarily
fails for incompleteness.

Just fix the packaging tools, it can’t be *that* hard.
The issue has been open for five years, isn’t that embarassing?

bye,
//mirabilos

Hi Thorsen,

Le 19/11/2019 à 20:30, Thorsten Glaser a écrit :

If you say so. I’m impatient to see your fix part of the next version.

Indeed, I filed that bug exactly five years (and a day) ago, never
bothered to actually work on it since (and you’re the first person to
actually care enough to reply), but I’m grateful if you feel interested
to get it fixed.

Regards

David

David Prévot dixit:

… as long as I don’t become the new maintainer because I happen to
be the last person to submit a patch… (had this happen to me multiple
times in Debian already).

bye,
//mirabilos