FS#16117 - 'depends' with version doesn't accept 'provides' without version
Attached to Project:
Pacman
Opened by Phillip Smith (fukawi2) - Thursday, 10 September 2009, 01:50 GMT
Last edited by Xavier (shining) - Wednesday, 16 September 2009, 12:58 GMT
Opened by Phillip Smith (fukawi2) - Thursday, 10 September 2009, 01:50 GMT
Last edited by Xavier (shining) - Wednesday, 16 September 2009, 12:58 GMT
|
Details
If a package 'depends' on something, including a version
number, and there's another package that 'provides' the
dependency for package A but without specifying a version
number, then the dependency is not satisfied.
Example: I have ha custom package of postfix called 'postfix-relay'. I make a separate package as I compile with custom spool directories etc and custom default config files. This package of course 'provides' postfix. I also use 'sqlgrey' with this package, which depends on 'postfix>=2.1' but until I specified that postfix-relay provides 'postfix=2.5' instead of just 'postfix' then when I tried to install sqlgrey, pacman wanted to uninstall my postfix-relay package and install the postfix package from extra. Rebuilding the 'postfix-relay' package with the version number in the 'provides' line solved the problem. I don't know if this is the expected/desired behaviour but I wanted to raise it to see what others think. I think it's reasonable given the rolling-release nature of Arch to have pacman assume that unless a version number is specified in the 'provides' line, then it is providing the latest / sufficient version to satisfy the 'depends=>X.y' of another package. But that's just my thoughts... |
This task depends upon
Closed by Xavier (shining)
Wednesday, 16 September 2009, 12:58 GMT
Reason for closing: Not a bug
Additional comments about closing: this is not a bug, but expected behavior.
about the not so informative output, this is not easy to improve, and is already covered by FS#7524
Wednesday, 16 September 2009, 12:58 GMT
Reason for closing: Not a bug
Additional comments about closing: this is not a bug, but expected behavior.
about the not so informative output, this is not easy to improve, and is already covered by FS#7524
a) assume that the dependency 'providing' is the latest; or
b) use the $pkgver from the dependency and compare against that?
Maybe a suffix for the 'depends' var if the pkgver must be explicit? eg:
depends=('postfix>=2.1!'
That is getting a bit inbred and complicated though....
Also, it is good to always remember that assumptions break systems.
Yes, assumptions often do break things.
How about a warning then?
"Package 'postfix-relay' can not provide 'postfix' for 'sqlgrey' because 'sqlgrey' depends on 'postfix>=2.1' and postfix-relay doesn't specify a version"
Or something similar... I'm just trying to think of ways to avoid hair-tearing time-wasting like I went through this morning ;)
resolving dependencies...
looking for inter-conflicts...
:: postfix conflicts with postfix-relay. Remove postfix-relay? [Y/n] n
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: postfix: conflicts with postfix-relay
This behavior was a deliberate choice we made when introducing versioned dependency, for that very reason (being careful)
About the warning message, I am not sure we can do that easily.
It seems we would need to keep the reason why a package was pulled (in this case, postfix was pulled to satisfy postfix>=2.1)
then when we have a conflict, compare all the dependencies that postfix satisfy versus the ones that the conflicting package postfix-really provides.
Quite weird..
Otherwise, we could also display a warning every time a unversioned provider cannot satisfy a versioned dependency, but then we would likely get a lot of spam and cluttered output that we don't want.
But Nagy is the expert here, so I would like to hear his opinion :)
1) Scan through installed packages for any that could 'provide' the required dependency
2) If an installed package can't satisfy version requirements, print error and continue
3a) Matching installed package is found -> all good
3b) No match found installed, continue with current behaviour (in this case, remove postfix-relay and install standard postfix)
I've never hacked pacman so I don't know if that's reasonable given the existing code, just my thought processes ;P
The following example justifies that:
I have mesa-git 20090509-1 installed on my system (mesa-git provides mesa). Without provision version number, pacman should not assume anything, for example mesa 20090509-1 assumption sounds just terrible. (Hint: Nothing guarantees that that my mesa-git is not "outdated".)
I am not sure about warnings. Those are helpful for detecting _packager_ bug, but I don't think that worth spamming pacman's output. Even if we print a warning, the end-user cannot do anything until the package is fixed, he can only do pacman -Sd sqlgrey, which is not recommended.