Bugzilla – Full Text Bug Listing
| Summary: | omni version should support 'debian package rules' | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Henrik Lindberg <henrik.lindberg> |
| Component: | p2 | Assignee: | P2 Inbox <equinox.p2-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | Ed.Merks, pascal, pwebster |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Henrik Lindberg
Most package managers have really really specific rules on versions. I'm kind of skeptical that we can express all these variants with omni version and I'm wondering if we are not better off using a concrete version class (like we have for OSGi for efficiency reasons), though even this will likely be a pain to code. Another approach is to try to canonicalize the debian version to something else (or maybe simplify the rule a bit_... but not sure how that works when the package space is open ended. (In reply to comment #1) > Most package managers have really really specific rules on versions. I'm kind > of skeptical that we can express all these variants with omni version and I'm > wondering if we are not better off using a concrete version class (like we have > for OSGi for efficiency reasons), though even this will likely be a pain to > code. > If every new encountered scheme requires additional implementation in omni version raw format, it is in practice the same as adding direct support for a particular version scheme in p2 as old clients would not be able to understand the format extension anyway. In this case, the raw (canonical) format is already capable of describing the version correctly (i.e. there is min and max string support), but there is no way to specify how to parse an original string. >Another approach is to try to canonicalize the debian version to something else >(or maybe simplify the rule a bit_... but not sure how that works when the >package space is open ended. I have a decent compromise that I use for now - in my use case (for now) I basically just need to validate that a version string is correct and do exact matching. > If every new encountered scheme requires additional implementation in omni
> version raw format, it is in practice the same as adding direct support for a
> particular version scheme in p2 as old clients would not be able to understand
> the format extension anyway. In this case, the raw (canonical) format is
> already capable of describing the version correctly (i.e. there is min and max
> string support), but there is no way to specify how to parse an original
> string.
I agree with you. I was just trying to propose a pragmatic solution for now :) Of course if omniversion can support this, then it is good.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. I think this issue has died. |