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

[Guillem Jover]

Heya!

On Tue, 2013-12-17 at 21:49:05 +0200, Eugene V. Lyubimkin wrote:
> Control: severity 575786 wishlist

> 2013-12-17 16:58, Guillem Jover:
> > Actually, this is a bug in cupt, let's reassign it then. Please see
> > the other related bug in apt #579790, for other details related to
> > the use of --force-* options.
> 
> 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? :)

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. Also they are marked as
“can seriously damage the system” (--force-help).

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.

> > > That's because the request to dpkg was not explicit enough. The way to
> > > do that is to create a “dpkg transaction”, by setting the apropriate
> > > selections so that dpkg knows what it can do. This is how the “venerable”
> > > dselect has worked all this time w/o ever requiring any kind of --force
> > > option.
> > > 
> > > The rationale is that dpkg does not really like to remove packages if not
> > > asked explicitly, and in a case like this, just removing the interface
> > > providing package might not be enough, and other packages might suddenly
> > > have unsatisfiable dependencies, and dpkg should not start removing stuff
> > > until the situation is ok. That's why either the user or the frontend
> > > should exactly specify what it can do.
> 
> Great, that sounds exactly what Cupt would want to do.

Perfect!

> > > Please see the test case on CPR interfaces in the dpkg test suite, as
> > > an example usage:
> > > 
> > >   <http://anonscm.debian.org/gitweb/?p=dpkg/pkg-tests.git;a=tree;f=t-conflict-provide-replace-interface;hb=HEAD>
> 
> That's a good start, but where do I find latest and greatest
> documentation of dpkg transactions so I can find what can Cupt rely on?
> If I'm not mistaken, the man page dpkg(1) has no mention of
> transactions.

Oh, I guess using the “dpkg transaction” terminology might have been
more confusing than necessary. It was just to convey how selections
can be thought of. The necessary docs should be in the man page, the
relevant bits are the --set-selections and -a|--pending modifiers to
the normal actions.

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; then it would first install
the Pre-Dependency requirements, and then all the rest; after that the
only thing remaning would be to remove/purge pending packages. In case
triggers have been delayed the frontend might want to run a pending
configure too.

(dselect uses --yet-to-unpack and the internal --predep-package for its
installation methdos, but I don't think cupt would require these at all?)

Hope that clarifies, and let me know if you think any of the interfaces
are not properly documented. I guess, though, it might make sense to write
something about this in the frontend.txt file.

Thanks,
Guillem