[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dpkg transactions

(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

Reply to: