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 pkga… 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 conversion). Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature