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.

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 11 December 2010 02:31, Kaiting Chen wrote:

On Fri, Dec 10, 2010 at 9:58 AM, Xyne 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