FS#12134 - Support for "conflicts"/"provides" across multiple packages
Attached to Project:
Pacman
Opened by G_Syme (G_Syme) - Saturday, 15 November 2008, 17:57 GMT
Last edited by Allan McRae (Allan) - Sunday, 22 April 2012, 11:50 GMT
Opened by G_Syme (G_Syme) - Saturday, 15 November 2008, 17:57 GMT
Last edited by Allan McRae (Allan) - Sunday, 22 April 2012, 11:50 GMT
|
Details
Summary and Info:
I'm looking for a general way for a set of packages to provide a single package and at the same point conflict with it. Example: There's a printer driver called brother-mfc260c in AUR which is orphaned, not working, and waiting to be replaced. But as the driver actually consists of 2 components, a native LPR driver, and an LPR-to-CUPS wrapper, which already come separate and also use different licenses, I want to provide 2 packages, namely brother-mfc260c-lpr and brother-mfc260c-cupswrapper (just like Brother itself does). From the info above, both packages share some files with brother-mfc260c, so both have to conflict with it. And *-lpr and *-cupswrapper together provide the functionality of the old package. As the LPR driver can be used without the CUPS wrapper, but the CUPS wrapper on the other hand needs the LPR driver to work, we can state that the CUPS wrapper depends on the LPR driver and also provides the functionality of brother-mfc260c. To summarize, we have: ---brother-mfc260c-lpr--- conflicts=('brother-mfc260c') ---brother-mfc260c-cupswrapper--- depends=('brother-mfc260c-lpr') provides=('brother-mfc260c=1.0.1') conflicts=('brother-mfc260c') But pacman doesn't like this setup, and complains: # pacman -S brother-mfc260c-cupswrapper resolving dependencies... looking for inter-conflicts... error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: brother-mfc260c-lpr: conflicts with brother-mfc260c-cupswrapper (FYI, brother-mfc260c was not installed, and the problem is independent of whether I try to install these packages from a local repo or manually via pacman -U, as this was also asked in the bbs thread[1]). This is because the conflicts statement is checked against the original package ~and all packages which provide that one~. AFAICT this is a design decision, so that alternative packages will automatically conflict with one another without being aware of each other because they conflict against a common package which they also provide. I'm not pretending to think I can convince you to alter this decision, as I don't know whether the alternative will be more practically, nonetheless because examples such as the one mentionend above seem to occur pretty seldom. And the example above I've "solved" by removing the provides statement from brother-mfc-cupswrapper, as there was no package depending on brother-mfc260c. But it would be great if there was a way to handle such situations. The only suggestion of which I can think which does not involve completely changing the way in which "provides/conflicts" are interpreted now, would be to somehow conclude from the dependencies, that in our example, brother-mfc260c-lpr and brother-mfc260c-cupswrapper would be regarded as a set, so that brother-mfc260c-cupswrapper wouldn't conflict against brother-mfc260c-lpr (although that one conflicts with brother-mfc260c which brother-mfc260c-cupswrapper provides) because it depends on it. But because "depends" on the other hand also works against packages which simply provide a package and are not the same, we're likely to get other anomalies... Another thought that's passing my mind right now would be to take a look at xorg. IIRC, we had a similar situation from xorg 6.9 (single package) to 7.0 (set of pacakges). May I ask how you solved that problem in the past, and whether that procedure would be applicable to problems like the example above? [1] http://bbs.archlinux.org/viewtopic.php?id=58632 P.S.: I this is more a Support Request than a feature request, just mention it, as I'm not entirely sure. |
This task depends upon
Closed by Allan McRae (Allan)
Sunday, 22 April 2012, 11:50 GMT
Reason for closing: Won't implement
Additional comments about closing: See Xavier's comment on 13 December 2009
Sunday, 22 April 2012, 11:50 GMT
Reason for closing: Won't implement
Additional comments about closing: See Xavier's comment on 13 December 2009
In fact pacman silently assumes that foo provides bar means that foo equivalent with bar (not that foo is member of a bar-equivalent package group, now this is the case). You are right, that foo requires bar and foo conflicts with bar should mean that foo conflicts with other bar provisions, not with its dependency (or this is a packaging error). This can be implemented easily, we have a alpm_dep_egde function for checking this. [But I have a little problem with this: foo depends on bar means, that bar is a *possible* dependency satisfies "bar" dependency (many bar provisions may exist). So a foo<->bar conflict can indicate that *this* bar dependency is not good. But this is an edge case, the situation should be resolved by more concrete specification of bar dependency...]. Personally I would prefer an option to specify "bar except (literal) baz" conflicts (brother-mfc260c-lpr conflicts with brother-mfc260c except brother-mfc260c-cups), because I don't like when pacman tries to figure out the packagers thoughts instead of precise specifications, but that would be too complicated. So I am waiting for the response of other devs.
---brother-mfc260c-lpr--- /* core */
conflicts=('brother-mfc260c')
provides=('brother-mfc260c=1.0.1')
---brother-mfc260c-cupswrapper---
depends=('brother-mfc260c-lpr')
/* conflicts is not needed here, the pulled -lpr dependency will ensure that. */
And I would put an install message to -lpr, that if you want to use this driver with cups, please install -cupswrapper package.
About your suggestion regarding the Brother printer driver pair, although it does not completely correspond to reality (brother-mfc260c-lpr alone does not provide brother-mfc260c), it is practical enough if we only have 2 packages of which our "set" consists (and a notice is needed nonetheless for potential users to understand that both packages are necessary to get the functionality of the old one). As for the message, our shiny new optdepends clearly come in handy here. ^^
But if I recall such an example as the Xorg split mentionend above, this would certainly not scale (having one piece provide xorg and having ~100 optdepends, of which all are needed).
So the best thing we can do now is to wait for the other devs' opinions.
I can work around this by adding the pkgrel to provides, but I don't think that it's correct that I should do so. I understand the arguments in favor of this functionality above, but perhaps add a check so that a package cannot conflict with its own dependency?
Quickie: Versioned conflicts are also allowed. What to do then? See also: http://bbs.archlinux.org/viewtopic.php?id=77647
So this is not so easy as it sounds. I can just repeat what I said earlier: "I don't like when pacman tries to figure out the packagers thoughts instead of precise specifications". Maybe an other packager can come up with an other example when the _current_ behavior is more useful ("foo<->bar conflict can indicate that *this* bar dependency is not good").
I think in this case the packager should workaround the problem. In the case above, I would use tremulous=1.1.0-6 (?) provision as you also mentioned. Since there is a notable difference between 1.1.0-5 and 1.1.0-6 this is not a bad idea at all imho...
And as it has been mentioned several times already, I am concerned that changing pacman behavior in any way would create more problems than it solves.
I will close this as 'won't implement' unless someone convinces me otherwise :)