(splitting of from #766758 as it is of topic for the RC bug) On Sat, Nov 15, 2014 at 06:24:16PM +0100, Guillem Jover wrote: > And w/o wanting to get tiresome with this, take into account that > frontends that use any of the dpkg --force-* options as normal course > of action, will most probably produce intermediate broken states. For Well, that is kinda the point to have intermediate broken states. If not, we would all be just doing dpkg -i *.deb, right? But no, we ask for the unpack/configuration of specific packages to have these packages out of the "broken" state space early as for a user/system there isn't much of a difference if dpkg is called a thousand times and in between these calls the system state is broken or if dpkg is called only once, but the call just takes an hour to complete in which the system is broken. The important/visible difference is which packages are broken for how long. Also, you tend to disregard all disadvantages of the usage of selections: Many systems have all sorts of strange dormant selections already you really don't want to pick up, but also don't want to just discard – after all its user configuration. As a user on the other hand I don't expect apt to do more than it was asked for, which it does if we would do a "dpkg --remove --pending" and the user happened to have some deinstall selections already.¹ Besides, its hard to get the information I have feed into it back out again: Without ever setting deinstall I have e.g. plenty of them on my system already (= all rc packages). Which leads me to my last point: I think its a horrible interface. It is not like I would be telling dpkg beforehand which packages I am going to install, so why are removes that special? And why do I have to share this information with everyone else on the machine, including the user? You keep mentioning "dpkg transactions": I have really no idea what you mean by that, but my personal vision is that it means "dear dpkg, please install A, B & C and remove D, E & F. Do it in any order you see fit. If you are done, they should be all in the requested states, otherwise tell me with a failure (expect if I said --no-triggers, then the trigger states are fine, too)." And while I am dreaming, lets say iteration two can also express "Oh, and if you can, prefer doing B first" (because that is openssh-server and user wants it operational at all times). That would allow apt (and presumably all other dpkg frontends) to drop all of the ordering code² and replace it with one giant dpkg call and everyone would be very happy as we now don't have more or less the same code in every frontend (+ dpkg itself), but in one place. In reality on the other hand I have to micromanage dpkg with individual commands in the right order, which I can only guess as I don't have all the information (triggers, maintainerscripts, fileconflicts, …) at hand to do it properly. And now, you are suggesting that I should make some of these commands be global "orders of the day" where I have no idea when they are executed, but it is nonetheless my responsibility to cancel the orders if something goes wrong during the day while micromanaging the rest.³ So that this is effectively increasing the amount of micromanaging I have to perform as I have to keep track of the status of the orders of the day now as well… Best regards David Kalnischkies ¹ On an intellectual level I have the same issue with all --pending operations, just that apt is described as going from one good state to another, so I have less problems saying that its okay for it to fix up all the mess currently present, rather than limiting itself to what it was explicitly told to do, with e.g. --configure --pending as this improves the situation. Unneeded removals on the other hand… ² expect for cdroms, but we could invent something much simpler. ³ not to mention that apts orders are promoted by e.g. a power failure to direct user orders because I obviously can't revert them in that case while all install requests are lost. Not exactly ideal. Also, temporary removes become very permanent this way. Very bad.
Attachment:
signature.asc
Description: Digital signature