Hi, 2013-12-18 06:57, Guillem Jover: > > I'm not sure can it be classified as "bug" or not (after all, it uses > > documented interfaces to achieve what is wanted), but I agree that if > > dpkg has some kind of transactions, using them might be an improvement > > from the current situation. > > Well, you filed the bug report on dpkg as important and bumped it to > serious at some point in time, so I guess you considered it enough of > a bug? :)
Yeah, I then thought relaying on Policy-mandated behavior, thus was the severity. Later Policy got changed into Breaks+Replaces, and just now I find that selections are preferred to --force-* options. Kinda different weight category IMO :) > Anyway, yes, cupt is using documented interfaces (I guess you refer to > the --force-* options), but that does not mean that those are the correct > ones for a frontend to be using, more so when another frontend (dselect) > has never required them :), mind you apt suffers from the same issue, and > I guess cupt just inherited that design from apt. Package scheduling is one of things I designed from scratch (3 times I think), up to this day I have no idea how apt's one works. But I guess some parts are similar if both libapt and libcupt assumed that certain combinations are only possible to schedule through --force. It probably could be a good idea for me to ask that explicitly years before. Well, better later than never. > Also they are marked as > “can seriously damage the system” (--force-help). True. Man page says they should be used only by those who understand them, and I thought front-end developers to be in this group. Some clause that 'selections is the better way when possible, especially for front-ends' would be welcome. Otherwise, honestly, selections doesn't come to mind at all. > And as I've mentioned before, cupt's --force-bad-path problem stems > from using the other --force-* options, because cupt is removing packages > required for dpkg and other Essential packages operation. Yeah, that was a side effect of "having" to use --force-breaks. If Cupt can avoid --force-breaks by using selections, I will be very happy to kill --force-bad-path, I never liked it in the first place. [...] > Ideally, the frontend would compute an upgrade solution, using whatever > method; setup the upgrade through the selections, by notifying dpkg of > which packages are to be removed/purged; If, say, front-end wants to change 100 packages and 50th fails e.g. an upgrade breaks, should be anything extra done for cleanup to not interfere with subsequent actions of same (or even different) front-ends? Or we are done if --clear-selections are always called before any other front-end actions? Will be dpkg or any front-end confused if they see some 'deinstall's which by some reason didn't get completed? Would it be better or worse if front-end sets selections on-demand, i.e. just before the action which needs that particular selection? Second question, are following assumptions right/guaranteed or not: a) Av1 is installed, A is selected for removal, B breaks Av1, front-end asks '--unpack B' -> dpkg will deconfigure A and unpack B and -> front-end can now freely unpack Av2 or remove Av1; b) Av1 is installed, A is selected for removal, B conflicts with Av1, front-end asks '--unpack B' -> dpkg will remove A and unpack B (possibly replacing it A on the fly if B replaces Av1). Third question, can selections help with circular dependencies, i.e., is there a way to install A and B if A depends on B and B depends on A without passing --force-depends at least once? -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++ GNU/Linux userspace developer, Debian Developer -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
