On Fri, 08 Apr 2016, Russ Allbery wrote: > So, where this goes wrong is the upower -> libimobiledevice4 dependency. > As you say, the dependency is correct (or at least correct-ish): we don't > want to dlopen everything and try to push all those patches upstream. But > this is the weakest link of this whole chain, yet has the strongest > dependency. > > I think a more correct fix would (unfortunately) involve a new binary > package field that we don't currently have: Depends-Shallow (for lack of a > better term) that acts like Depends *except* disables Recommends > processing for anything below the shallow dependencies in the tree. So if > everything you're installing only Depends-Shallow on libimobiledevice4, > you don't get the recommendation; if anything straight depends on it, you > do.
Make it "downgrades recommends to suggests" and it might even work well. But since there exists recommends one is much better off never downgrading, we might end up needing a recommends-strong field as well that would never be downgraded, to avoid the need to upgrade such recommends to depends. At least it would end there with two extra headers (or some other way to annotate recommends dependency headers in these two ways), so it is still something that looks like it could work. But how much of a trouble would such changes cause for the dependency solvers? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
