Allow qualifiers like pre, post, preun, ... for weak dependencies, too

[ffesti]

We are using weak dependency for ordering now. So it make sense to also
qualify weak dependencies with the time they are needed/wanted in the
transaction to make use of this information in ordering.

Especially (posttrans) could be useful to remove weak deps from dependency
loops during ordering when they are only needed after the installation.

Resolves: #624

[pmatilai]

I almost hit merge, but then I started wondering what exactly do things like pre/post mean on reverse dependencies. Too late in the afternoon for this sort of thing...

[ffesti]

May be this also deserves a test case or two.

[ignatenkobrain]

It might help in absolutely same cases where you would use forward weak deps, but you simply can't do that by policy like Fedora has. Imagine checking for presence of ffmpeg in post, but you are not allowed to use Recommends (post): ffmpeg by Fedora policy. However, even this is stupid, in this case you can do this from ffmpeg side with Supplements(post): original-package.

[pmatilai]

Well, Fedora policies are irrelevant here.

[ignatenkobrain]

@pmatilai I am just saying that while this is not something what 99.9% people would use (reverse weak deps with qualifiers), there might be a use-case created by Fedora policies.

[Conan-Kudo]

I definitely can see use-cases for this with some of the stuff I do for $DAYJOB. For example, if an interpreter has multiple valid implementations, being able to use Suggests(*) would allow the solver to be told which one to prefer for that.

Generally speaking, if we allow strong dependencies with qualifiers, we probably should allow the weak dependencies too.

[pmatilai]

Accepting qualifiers in weak dependencies seems like a no-brainer obvious thing as such, I'm merely pondering the case and consequences of qualifiers in reverse dependencies.

[Conan-Kudo]

@pmatilai My thought there is that if scriptlets do progressive enhancement (that is, they check for things and use if they're available), then this would be useful functionality for that.

We used to have a number of those in Fedora, but these days I see them more with third party packages (such as the ones I do for $DAYJOB).

[ffesti]

Another interesting combination would be the new meta qualifier from #1028 to allow keeping the weak deps out of the dependency mess. This would obviously also be useful for reverse dependencies. May be even more than for forward ones.

[pmatilai]

Yeah, the thing is that I can easily see how the ability to affect somebody elses install order can be a powerful thing - also in its ability to break things by introducing stronger dependency loops from the outside.

[pmatilai]

I'd be a lot less nervous about adding this (in particular the reverse case) if we prioritized strong dependencies over weak ones in ordering...

[pmatilai]

Anniversary coming up soon.

And in the meanwhile the fear of stronger weak dependencies is keeping us from expressing unordered weak dependencies which could help the ordering situation, which is silly. The qualifiers make as much sense for weak deps as they do for regular ones, if our ordering algorithm can't cope then we'll just tame the data a bit...

I just pushed commit d6353c9 to ignore the strong order hint flags from weak deps in the ordering algorithm for now to let this proceed.