[pacman-dev] [PATCH] test version range restrictions corner case
The test introduced herein illustrates a behavior that may be unexpected to package writers. It creates a package "pkg3" that is configured to depend on a "dependency" which version is between 3 and 4, inclusive. Two other packages are already present, providing "dependency" in version 2 and 5, respectively. So, the situation looks roughly like this: pkg1 pkg3 pkg2 provides depends on provides | <------------> | version __________2____________3____________4____________5___________... This seems to be enough to satisfy pacman when installing "pkg3". From an iterative standpoint, this is completely logical: First, the requirement "dependency>=3" is checked. There is a package that satisfies this restriction, it is called "pkg2". Afterwards, "dependency<=4" is covered in the same way by "pkg1". Nonetheless, what a package writer intends when specifying depends=('dependency>=3' 'dependency<=4') is most probably that pacman should only allow this package to be installed when there indeed is a package present that provides a version of "dependency" that lies _between_ 3 and 5. Signed-off-by: Dominik Fischer <d dot f dot fischer at web dot de> --- This behavior may be intended though. If so, this corner case should perhaps be noted in the documentation. Please review and comment. test/pacman/tests/TESTS | 1 + test/pacman/tests/deprange001.py | 17 +++++++++++++++++ 2 files changed, 18 insertions(+) create mode 100644 test/pacman/tests/deprange001.py diff --git a/test/pacman/tests/TESTS b/test/pacman/tests/TESTS index bee7c8e..f35ec1a 100644 --- a/test/pacman/tests/TESTS +++ b/test/pacman/tests/TESTS @@ -15,6 +15,7 @@ TESTS += test/pacman/tests/depconflict110.py TESTS += test/pacman/tests/depconflict111.py TESTS += test/pacman/tests/depconflict120.py TESTS += test/pacman/tests/dependency-cycle-fixed-by-upgrade.py +TESTS += test/pacman/tests/deprange001.py TESTS += test/pacman/tests/deptest001.py TESTS += test/pacman/tests/dummy001.py TESTS += test/pacman/tests/epoch001.py diff --git a/test/pacman/tests/deprange001.py b/test/pacman/tests/deprange001.py new file mode 100644 index 0000000..bab52fa --- /dev/null +++ b/test/pacman/tests/deprange001.py @@ -0,0 +1,17 @@ +self.description = "undetected conflict with version range" + +lp1 = pmpkg("pkg1") +lp1.provides = ["dependency=2"] +self.addpkg2db("local", lp1) + +lp2 = pmpkg("pkg2") +lp2.provides = ["dependency=5"] +self.addpkg2db("local", lp2) + +p = pmpkg("pkg3") +p.depends = ["dependency>3", "dependency<4"] +self.addpkg(p) + +self.args = "-U %s" % p.filename() +self.addrule("PACMAN_RETCODE=1") +self.addrule("!PKG_EXIST=pkg3") -- 2.6.3
On Mon, 7 Dec 2015 21:37:09 +0100 Dominik Fischer
This behavior may be intended though. If so, this corner case should perhaps be noted in the documentation. Please review and comment.
Actually that is exactly what some of our packages want to do so I'd consider it a bug. Nice find!
Nonetheless, what a package writer intends when specifying
depends=('dependency>=3' 'dependency<=4')
is most probably that pacman should only allow this package to be installed when there indeed is a package present that provides a version of "dependency" that lies _between_ 3 and 5.
I'd think so too. Perhaps a reason for this confusion is the choice of syntax for version constraints? I don't know how much work and hassle it would be to change/expand it, but it might be worth at least considering adopting a less ambiguous syntax. One source of inspiration could be Apache Ivy, where ranges are specified much like in math: `[3.14,)` for any version >=3.14, `(3.14,4)` for >3.14 and <=4. I'm not a Pacman developer and I only manage a small handful of packages, which don't currently use version constraints, so please disregard me if I'm completely clueless. :)
If this is the intended way to specify a version range, I don't see any need to introduce a dedicated syntax. It just has to be ensured that when checking dependencies, all requirements for a package have to be satisfied by the same package. Then, the given scenario would be rejected because "pkg1" providing "dependency=5" meets "dependency<=4", but "dependency>=3" is only met by "pkg2" providing "dependency=2", which are not the same. Unfortunately, I lack proper knowledge of the libalpm code responsible for this to offhandedly implement a solution.
On 08/12/15 06:37, Dominik Fischer wrote:
The test introduced herein illustrates a behavior that may be unexpected to package writers.
It creates a package "pkg3" that is configured to depend on a "dependency" which version is between 3 and 4, inclusive. Two other packages are already present, providing "dependency" in version 2 and 5, respectively. So, the situation looks roughly like this:
pkg1 pkg3 pkg2 provides depends on provides | <------------> | version __________2____________3____________4____________5___________...
This seems to be enough to satisfy pacman when installing "pkg3". From an iterative standpoint, this is completely logical: First, the requirement "dependency>=3" is checked. There is a package that satisfies this restriction, it is called "pkg2". Afterwards, "dependency<=4" is covered in the same way by "pkg1".
Nonetheless, what a package writer intends when specifying
depends=('dependency>=3' 'dependency<=4')
is most probably that pacman should only allow this package to be installed when there indeed is a package present that provides a version of "dependency" that lies _between_ 3 and 5.
Signed-off-by: Dominik Fischer <d dot f dot fischer at web dot de> ---
This behavior may be intended though. If so, this corner case should perhaps be noted in the documentation. Please review and comment.
Pulled with a change to the description (describe why this is wrong) and added the expected failure marker. Also corrected the ">" and "<" in the test to "<=" and ">=" to match the commit description. A
Thanks for the pull. I saw it appeares as XFAIL in the master branch. Is this enough or should I also file this in the bug tracker [1], so that the issue will not be forgotten? [1]: https://bugs.archlinux.org/index.php?project=3
On 18/01/16 02:37, Dominik Fischer wrote:
Thanks for the pull. I saw it appeares as XFAIL in the master branch. Is this enough or should I also file this in the bug tracker [1], so that the issue will not be forgotten?
Feel free to add the bug - the constant XFAIL is enough to remind some of us, bug the bug won't hurt. Allan
Bug filed at https://bugs.archlinux.org/task/48252 . Thanks for your consideration.
participants (4)
-
Allan McRae
-
Dominik Fischer
-
Emil Lundberg
-
Florian Pritz