On 14 November 2012 20:24, Axel Beckert <a...@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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org