On Tue, 2014-09-02 at 15:30:44 +0200, Petter Reinholdtsen wrote: > [Guillem Jover] > > The problem is that it would make the dependency resolution harder, > > as that's in fact changing the Recommends to Depends. So dpkg would > > have less leeway when there are dependency cycles and similar. But > > see below. > > I've tried to understand this comment, but failed so far. My proposal > would be regarding the ordering of the postinst for the set of > packages already selected for installation, and thus not really affect > the dependency resolution as such. Also, my proposal is for cycle > free dependency trees, as package sets with cycles are already broken > at a random location and thus any hope of predictable ordering of > postinst execution is gone already.
If the Recommends act as a proper Recommends on the dependency side, and as Depends on configuration ordering time then a frontend would not be required to install it before the depending package, or even on the same install run (as in dpkg invocation). Otherwise to get the guarantee you seek, they actually need to be handled as if they were actual Depends. Turning anything that is currently a Recommends into something stronger means (besides ripping the initial distinction away) that suddenly many more dependency cycles would appear which implies dpkg will need to break cycles at random, in which case you again might lose the guarantees you were seeking. Hope that explains. Regards, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
