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

Re: dpkg transactions

On Tue, Jan 13, 2015 at 09:39:36PM +0100, Guillem Jover wrote:
> Ok, coming back to this, now that the big stuff has passed by. Be warned
> this is a long reply, though. :)

This isn't going to be short either and I don't even reply to everything
as "big stuff" isn't really over for me and given that we disagree on the
first line everything else hopefully just follows suite (or at least
makes a bit more sense).

> On Sun, 2014-11-23 at 18:40:32 +0100, David Kalnischkies wrote:
> > 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.
> My point is that there's never a need for intermediate broken states,
> those are artificially inserted there by frontends. And dpkg
> internally never produces those broken states.

Well, that would be nice, if it would be true. dpkg obviously can
produce broken states - everytime a package maintainerscript fails for
example - but lets ignore that and focus on the first claim, that
intermediate broken states are never needed:

Package: pkga
Version: 2
Depends: pkgb, pkgc

Package: pkgb
Version: 2
Conflicts: pkgc (<< 2)

Package: pkgc
Version: 2
Conflicts: pkgb (<< 2)

Assuming you have all these packages already installed in version 1,
what do you believe the solution to be in an upgrade scenario?

Okay, we could remove 'pkga' and one of the other two to have a really
clean upgrade, but that easily leads into hell if something depends on

So, the only 'real' solution is to remove either 'pkgb' or 'pkgc'
temporarily. dpkg doesn't do it, so apt is spoon-feeding (as you said
it) to it with an explicit remove, which obviously is an intermediate
broken state.

Now, I hear you saying "selection to the rescue", but at least at the
moment that doesn't work for various reasons: First, you need to know
which package will dpkg choose to unpack first and hence mark the other
for deinstall. Secondly, that needs --auto-deconfigure even through
there is nothing automatic here… quiet the opposite. And lastly, which
is the most important thing here: If you do both right, dpkg is happily
running, but the chosen to-be temporary removed is never really removed,
it is just deconfigured so I have just "tricked" dpkg into demoting
a Conflicts to a Breaks it seems (which smells like a bug).

In an ideal world, apt wouldn't be required to spoon feed here at all…

You see, if I can construct a simple 3 package universe violating your
"no need for immediate broken states" I have my doubts that it is going
to survive very long in real world situations even if I would be happy
if it would be the case.

> I've to point out thought that there's quite a distinction between the
> different selection states.
>   hold:
>     This one is going to be taken into account on upgrades and
>     similar already anyway (except with --force-hold).

It is the only thing libapt is honoring. I think aptitude still ignores
it in some cases (bug, but hard to fix). btw: --force isn't needed
to upgrade a held package. Haven't actually tried why, but I know that
apt isn't using this --force flag and still can install kept back
packages if it is itself forced to do it.

> > 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.¹
> There's a difference between an explicit action like «apt install» or
> «apt remove» and «apt full-upgrade». Only something like the latter
> should probably be doing a «dpkg --remove --pending».

Theoretically maybe, in practice the code calling dpkg has no idea what
lead to it being called in the first place. It just knows which state we
are in now and which state is aspired on a per-package level. No idea if
this is a 'dist-upgrade' or a mile-long 'install' command – or for that
matter a 'remove foo+ bar+' command. Such a difference would make even
less sense for other frontends libapt is catering to, so whatever we do
with dpkg has to be a one-size-fits-all thing.

> > 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).
> I'm not sure I understand this comment, packages in «rc» have been
> removed, and as such where requested for deinstall, which is the
> current state they are in.

The point being: I request the removal of 'foo', but asking dpkg for
which packages I requested for removal tells me also 'bar' as this
happens to be in 'rc' (maybe as well now, depending on when I ask).

> > Which leads me to my last point: I think its a horrible interface.
> It's maybe a bad interface if including the "install" states because
> there's also only support for one available file, and one possible
> version candidate from that available file, but you can probably ignore
> those for now. This part of the interaction between dpkg and frontends
> does not worry me much for now. I'd like to ideally provide something
> better in the future, but that will require design work. What I'm
> proposing is already there.
> Or are there other parts of the interface that you do feel are not
> good? I'd be really interested to know.

Well, I said that I think it is horrible as its persistent. If I say
"apt-get install foo" and press 'N' in that interaction apt forgets
about the fact that I ever asked. Even if I say 'Y' here, but something
down the line decides its not okay after all (e.g. I am removing the
currently running kernel and so have second thoughts on the debconf
warning) apt happily forgets. Now, with selections, there is no implicit
forget anymore: The kernel is still marked for removal, which might be
okay, but the pkgb from above is also still marked for removal, which is
absolutely not okay as the user never agreed to this…

… which is what I meant with increased micromanagement as I have
non-trivial work to do to 'restore' the forget behavior and it would
still not be bulletproof (e.g. power failure). Previously, if pkgb was
gone but pkga is installed, I can assume that pkgb should come back, but
if is marked for removal … do I have to assume now that pkgb should be
removed or should it be ignored?

> > ¹ 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…
> Well something I've always found a bit perplexing is that when apt
> finds that the dpkg status is in an inconsistent state it requests
> the user to run «dpkg --cofigure -a», which seems odd to me (instead
> of doing it itself :).

It isn't doing it for all states. Usually it just behaves as usual and
all it tells the user about is "%lu not fully installed or removed" in
the 'one line' (which in that case is two line) summary at the end of
the solution. It does through if it finds /var/lib/dpkg/updates to
contain something 'interesting'. Why? No idea. It comes straight from
2001 (potentially older as it is part of a mega-commit in the svn->arch

Best regards

David Kalnischkies

Attachment: signature.asc
Description: Digital signature

Reply to: