Optimize duplicate conflicting versions

[stof]

When a package has several vulnerabilities, the generated conflict constraint may be much more complex than necessary. See for instance the rule for FOSUserBundle (much simpler than the symfony one):

>=1.2.0,<1.2.1|>=1.2.0,<1.2.4|>=1.2.0,<1.3.0|>=1.3.0,<1.3.5|>=1.2.0,<1.2.5|>=1.3.0,<1.3.3

The third constraint is a superset of the first 2 ones (and of the 5th one). Deduplicating constraints would make the dependency resolution much easier for Composer later.

[stof]

Note that in this case, it should be generated as >=1.2.0,<1.3.0|>=1.3.0,<1.3.5, or >=1.2.0,<1.3.5

[Ocramius]

Considered that, but didn't yet start working on a normalizer for version constraints.

[reiz]

@Ocramius Not much I can say to that one. We parse that kind of expressions at VersionEye but we do not normalise them. Our algorithm takes a set of all versions from the package, evaluates each expression sequentially and skips versions after each expression. The algo. ends up with a small subset of versions and from that one we take the newest.

In general I don't like such expressions. But currently I have no better idea :-/

[Ocramius]

@reiz no problem, thanks for the input anyway :-)

[beberlei]

@Ocramius i think a simple way would be to partition into buckets by exact min version and then find the max version in that bucket and drop all the others.

[Ocramius]

@beberlei that's a good first optimization step, yes

[Ocramius]

For now, I could build something around an opinionated parser that assumes http://regexper.com/#%2F%3E%28%3D%29%3F%28\d.%29*\d%2C%3C%28%3D%29%3F%28\d.%29*\d%2F or ignores everything

Together with this opinionated horror: https://3v4l.org/rb94f

[lyrixx]

I'm pretty sure @hoaproject has something for that.

[stof]

@Ocramius take care of the case of constraint without a lower bound (to indicate that all older versions are affected). this is possible in the advisory database.

[Ocramius]

I produced a first prototype in #13. If you are interested, please do review. It doesn't cover open ended ranges yet.

[Seldaek]

Just in case it helps, we have composer/semver as a standalone bit now, with some utilities to parse/match stuff. I kinda doubt it is of much help for the problem at hand though.

[Ocramius]

@Seldaek that's the same stuff we wanted to patch for this sort of issue :P (the stuff you mention in your keynote, remember?)

I think we will be fine with an opinionated matching for another 3~4 years here /cc @asgrim

[Ocramius]

Closed via #13