On 30 Sep 2000, Manoj Srivastava wrote: > But only in the interim, correct? After the installation > process is all done, the dependencies are all satisfied. During > installation dependencies are broken, yes. Unless I am mistaken, dpkg > tries to go from a state where the dependencies are satisfied, > through an installation porocess, and, barring errors, reaches a > state where the dependencies are satisfied again.
No, you are confusing dpkg's goals with APT's high level goals, they are seperate. dpkg has no notion of a target state, it is just a dumb install tool, so it is making the best judgements it can, assuming something else is making a descision on target state. Initialy this was dselect (in a kind of haphazard way) and now it is also libapt. dpkg is primarily only concerned with the package it is operating in, except with processing conflicts which are checked in the 'reverse' direction. People have tried to 'fix' this, but it really isn't broken, see my extensive past commentary on this matter. > If there are no other objections, could we move to have this > ratified as part of policy? I'll start the process unless someone has > a serious objection. I feel all references to 'dselect' should be removed, or writen in a more general way so that they can define a policy that is common to all the installer front ends (dselect, apt-get, capt, aptitude, gnome-apt, stormpkg, etc) A footnote indicating that 'dpkg' refers to any arbitary .deb install tool would be good too. Jason
