[Aptitude-devel] Bug#693144: Bug#693144: aptitude should honour explicit installation request in connection with markauto package

[Daniel Hartwig]

On 14 November 2012 20:24, Axel Beckert <abe at debian.org> wrote:
> Daniel Hartwig wrote:
>> and it does not cause serious problems.
>
> I wouldn't be so sure here, as it changes the behaviour on the
> commandline subtly but severely if you rely on the current behaviour
> that it doesn't change the markauto state.

Yeah, I meant that the current behaviour does not cause problems: a
reason to not change it.

>
> BTW, would that change the behaviour when you press + on a package
> marked as auto in interactive mode, too? That'd be very annoying when
> doing selective upgrades interactively.

Indeed that would be annoying!  So, no, it wouldn't change.  I prefer
to think of the interactive “+” as “upgrade or install this package”,
where the command line has distinct commands for install and upgrade.

>
>> > Interestingly, the interactive behaviour is different here from the one
>> > on the command line.  If I hit '-' on rsstail and the '+' on openssl it
>> > would keep openssl and mark it as manually installed.
>>
>> Indeed.  The interactive processing is different, with auto-removals
>> processed immediately.  It is equivalent to:
>>
>> # aptitude remove --schedule-only rsstail
>> # aptitude install --schedule-only openssl
>> # aptitude install
>>
>> For various reasons, the semantics must be different here than when
>> specifying all actions at once.
>
> I'd be happy if there would be a possibility to do those all in one
> command, because aptitude needs quite some time for startup and
> finish.

With the apt-get-style handling of install aka “openssl+” this
particular case will not cause issues anymore.  Any way, I have
though about that much while exploring the depths of aptitude, and
worked out a way to do this, see below.

First, let me digress for a moment:

The command line is a two-pass algorithm: marking only the requested
packages first, then handling the dependencies and auto-removals
after.  This is very much desired (in most cases), because it allows
control over how dependencies are satisfied:

# cat Packages
Package: foo
Depends: bar

Package: bar
Depends: gnome, postgresql, apache2

Package: minimal-bar
Provides: bar

# aptitude install foo             ## installs many
# aptitude install foo minimal-bar ## installs two

> The same counts for -u only working for interactive mode, but
> not for commandline mode.

I can only think that this is not on the command line because of:
# aptitude update && aptitude install foo

If startup times weren't so bad, it's not a problem.  I know we can
improve the startup time quite a bit (i.e. only do actions that are
needed).  Personally, I am in favour of staying relative compatible
with apt-get's CLI, but am flexible.

>
> Or in other words, it would be cool if you could pass parameters to
> aptitude so that you can do non-interactively the same things you
> would do interactively. (Doesn't need to be any of the current
> commands or syntax for me.) Because that's what Elmar and me are
> trying to do with aptitude-robot.

And the other way!  The curses interface can not do the minimal-bar
example… yet.  This is on my deep space TODO:

* Refactor actions from curses, ui to a common backend
* Eval prompt for curses
* Real shell mode, like the problem resolver prompt but more general

# aptitude --shell
aptitude> - foo
Removing foo.
Auto-removing foo-core.
aptitude> + foo-core bar
Marking foo-core as manually installed and keeping installed.
Installing bar.
Auto-installing bar-core, libbar1.
aptitude> go
…

and also the alternative argument-style:

# aptitude remove foo -- install foo-core bar
…

and also in curses, similar to eval-expression in emacs (“M-:” to
bring up a prompt).  All using the same core, shared with “+” and
others in curses.

Each action takes one or more packages and search patterns, and uses
the same two-pass algorithm as on current command line.

>
> (I can file separate wishlist bugs for those things, if wanted.)

Not really needed, unless by chance someone is interested in picking
up one of the smaller tasks, and we already have lots of those :-)
Maybe just for “-u” on the command line and similar small ones.