[pacman-dev] Alternative dependencies.
Hi, Would it be possible to implement support for alternative dependencies, e.g. a package that could use either wget or curl to handle downloads? I'm not asking for this to be implemented. I'm just asking whether there are any technical limitations to such an approach. I know that "provides" can be used to do this, e.g. openjdk6 and jre both provide java-runtime to satisfy that dependency in other packages. The approach is limited though. Using the example above, we couldn't simply add "provides=('download-client')" to both curl and wget because they are not interchangeable. The basic usage case is when an application is capable of detecting any one of a number of different external apps that it can use to satisfy a given dependency. There is currently no way to depend on "at least one" of those. I can imagine a very simple syntax for this too, e.g. "depends=('curl || wget')" so the question is whether the dependency-handling mechanism could be adapted to check for alternatives. If none are found, it could probably use the upcoming "provides" selection dialogue to allow the user to choose the desired dependency. So, would that be possible? Also, would that be acceptable? Again, I'm not asking anyone to do this. I'm just inquiring about the possibility. Regards, Xyne
On Fri, Dec 10, 2010 at 8:58 AM, Xyne <xyne@archlinux.ca> wrote:
Hi,
Would it be possible to implement support for alternative dependencies, e.g. a package that could use either wget or curl to handle downloads?
I know that "provides" can be used to do this, e.g. openjdk6 and jre both provide java-runtime to satisfy that dependency in other packages. The approach is limited though. Using the example above, we couldn't simply add "provides=('download-client')" to both curl and wget because they are not interchangeable. Yes, this is definitely a slightly different problem. To continue your sentence, "not interchangeable in all cases".
The basic usage case is when an application is capable of detecting any one of a number of different external apps that it can use to satisfy a given dependency. There is currently no way to depend on "at least one" of those. You went abstract here- how many real packages would benefit from this sort of thing at the moment? What are they?
I can imagine a very simple syntax for this too, e.g. "depends=('curl || wget')" so the question is whether the dependency-handling mechanism could be adapted to check for alternatives. If none are found, it could probably use the upcoming "provides" selection dialogue to allow the user to choose the desired dependency. I'm sure we could, and the syntax isn't all that bad.
So, would that be possible? Also, would that be acceptable? Possible yes. Acceptable- I don't have any serious objections. The only thing that comes to mind is the likelyhood of abuse as a replacement for provides, when that is the better facility to express this.
-Dan
Dan McGee wrote:
The basic usage case is when an application is capable of detecting any one of a number of different external apps that it can use to satisfy a given dependency. There is currently no way to depend on "at least one" of those. You went abstract here- how many real packages would benefit from this sort of thing at the moment? What are they?
Well, a concrete example would be pbget, which checks for both curl and wget, although that's not what led me to ask. I wrote a script yesterday that does the same thing (checking for wget or curl) [1] and it made me wonder about how that could be generalized. I can't think of any other real examples right now but I know that this has come up before. Another likely example would be "libarchive || tar" when either bsdtar or tar could be used.
So, would that be possible? Also, would that be acceptable? Possible yes. Acceptable- I don't have any serious objections. The only thing that comes to mind is the likelyhood of abuse as a replacement for provides, when that is the better facility to express this.
I agree that it could be abused but they are clearly separate use cases and it would "simply" be a matter of enforcing policy: If both packages contain a standard library or application that can be used agnostically by another package then they should use "provides". If not, then use the alternative dependency syntax. As for the "need" for this, I would say that it's something which could facilitate different cases and that if it were available then it would get used. [1] http://arch.localhost:35620/scripts/pacman/#pacget
Xyne wrote:
Well, a concrete example would be pbget, which checks for both curl and wget, although that's not what led me to ask.
Um, apparently it doesn't. Something that I've written does though, or at least used to.
Hi,
Would it be possible to implement support for alternative dependencies, e.g. a package that could use either wget or curl to handle downloads?
I'm not asking for this to be implemented. I'm just asking whether there are any technical limitations to such an approach.
I know that "provides" can be used to do this, e.g. openjdk6 and jre both provide java-runtime to satisfy that dependency in other packages. The approach is limited though. Using the example above, we couldn't simply add "provides=('download-client')" to both curl and wget because they are not interchangeable.
The basic usage case is when an application is capable of detecting any one of a number of different external apps that it can use to satisfy a given dependency. There is currently no way to depend on "at least one" of those.
I can imagine a very simple syntax for this too, e.g. "depends=('curl || wget')" so the question is whether the dependency-handling mechanism could be adapted to check for alternatives. If none are found, it could probably use the upcoming "provides" selection dialogue to allow the user to choose the desired dependency.
So, would that be possible? Also, would that be acceptable?
Again, I'm not asking anyone to do this. I'm just inquiring about the possibility.
Well, I am not against it neither. In fact, your concept is identical to "provides" imho, with one important difference: With provides, the dependency packages also must be modified (in your example: curl and wget by adding provides=download-client [*]), which simply doesn't work always (see AUR packages, for example). With alternative dependencies, the packager needn't modify wget or curl, so he gets more freedom. In addition, less crap is added to sync database (no ugly provisions). It should be straightforward to implement, if needed. However, provision-like problems would appear (see the pactests): How to resolve "curl || wget" in resolvedeps? Pick one "satisfier"-package randomly, select the first one, ask user etc.? NG [*] Btw, download-client provision is acceptable imho (if alternative dependencies won't be implemented).
Nagy Gabor wrote:
Well, I am not against it neither. In fact, your concept is identical to "provides" imho, with one important difference: With provides, the dependency packages also must be modified (in your example: curl and wget by adding provides=download-client [*]), which simply doesn't work always (see AUR packages, for example). With alternative dependencies, the packager needn't modify wget or curl, so he gets more freedom. In addition, less crap is added to sync database (no ugly provisions).
I think there is a clear difference and that both have their own uses. Consider openjdk6 and jdk. Both provide executables named "java" and "jar" (among others). They behave identically, i.e. they accept the same arguments and do the same thing the same way, or at least they should. A package that needs to use "java" or "jar" doesn't need to know or care where they came from. It makes sense that openjdk6 and jdk should both provide "java-environment" as it is something standardized. On the other hand, curl and wget cannot both provide "download agent" because they cannot be used the same way. They have different names, accept different options and behave differently (wget saves the download to a file by default, curl pipes it to std out, etc). Of course, both can behave the same way with the right options but the package that can use either one needs to know what it's using and adapt to it. The same thing applies to bsdtar vs tar. They have many options in common but they are not identical and cannot replace each other in all contexts. They also have different names. You're right that "provides" require the maintainer of a dependency to update the "provides" array, but any package that implements a standard (library, executable, etc) should already provide that anyway, and "provides" should only be used in such a case. For all others there would be alternative dependencies which would indeed give the packager more freedom.
It should be straightforward to implement, if needed. However, provision-like problems would appear (see the pactests): How to resolve "curl || wget" in resolvedeps? Pick one "satisfier"-package randomly, select the first one, ask user etc.?
I thought the plan was to open a dialogue to select "provides" in the future. This could be used with alternative dependencies too.
On Fri, Dec 10, 2010 at 9:58 AM, Xyne <xyne@archlinux.ca> wrote:
Hi,
Would it be possible to implement support for alternative dependencies, e.g. a package that could use either wget or curl to handle downloads?
What kind of Arch user doesn't have both wget AND curl? Blasphemy. Okay, to be serious here I see where you're coming from but I don't know if there are quite enough packages in the repository that would benefit for this to be worth it. Any move that looks like Gentooification I think should be done very carefully after much consideration. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On 11 December 2010 02:31, Kaiting Chen <kaitocracy@gmail.com> wrote:
On Fri, Dec 10, 2010 at 9:58 AM, Xyne <xyne@archlinux.ca> wrote:
Hi,
Would it be possible to implement support for alternative dependencies, e.g. a package that could use either wget or curl to handle downloads?
What kind of Arch user doesn't have both wget AND curl? Blasphemy.
Okay, to be serious here I see where you're coming from but I don't know if there are quite enough packages in the repository that would benefit for this to be worth it. Any move that looks like Gentooification I think should be done very carefully after much consideration. --Kaiting.
Well, yeah, portage does have this feature IIRC. But that doesn't mean it's bad. Anyway, fortunately most of the OR cases are optdepends, and as it is (not) implemented currently, it can be as simple as: 'foo: for xyz, or' 'foo: for xyz' Instead of: 'foo: for xyz' 'foo: for xyz' Which I see a lot, but aren't necessarily AND optdepends. -- GPG/PGP ID: B42DDCAD
participants (5)
-
Dan McGee
-
Kaiting Chen
-
Nagy Gabor
-
Ray Rashif
-
Xyne