[Cupt-devel] Bug#575786: cupt: should use selections instead of --force-* options

[Eugene V. Lyubimkin]

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