[Aptitude-devel] aptitude: cmdline actions ignoring -o options

[Daniel Hartwig]

retitle 587671 aptitude: cmdline actions ignoring -o options
usertags 587671 + config next
forcemerge 587671 629590 652234
--

Hello

These are all the same issue caused by the logic in main.cc:

1. load config files
2. set some "state variables" from config/defaults

  char *status_fname=NULL;
  string package_display_format = aptcfg->Find(PACKAGE
"::CmdLine::Package-Display-Format", "%c%a%M %p# - %d#");
  ...
  string width=aptcfg->Find(PACKAGE "::CmdLine::Package-Display-Width", "");
  ...

3. process options in order
3a. most options update the state variables

	case 'F':
	  package_display_format=optarg;
          version_display_format = optarg;
	  break;
	case 'w':
	  width=optarg;
	  break;

3b. some options (and any use of `-o') update the config

	case 'o':
          ...
		aptcfg->SetNoUser(key, value);

4. run requested action based on state variables, not config

	  else if(!strcasecmp(argv[optind], "search"))
	    return cmdline_search(argc-optind, argv+optind,
				  status_fname,
				  package_display_format, width,
				  sort_policy,
				  disable_columns,
				  debug_search);


So the problem is that during this initial phase aptitude has two
inconsistent ideas about it's configuration -- the state variables and
the aptcfg object.  Changing most config options via `-o' is never
noticed by the state variables.


I am inclined towards the following course of action:

 i. Modify the order of things above so that the state variables are
    set *after* processing the command line options, which means
    changing the options of 3a. to modify aptcfg instead of these
    variables.

    This fixes the immediate problem of -o options being ignored.

ii. Investigate how many of these state variables are really needed
    and migrate most of them to having each action refer to aptcfg
    directly.  Some points worth considering:

    - the curses ui dynamically updates aptcfg and the state variables
      must be updated accordingly (duplicated effort and storage =
      error prone; though I assume this is handled by registering
      signals)

    - there is a lot of passing of the state variables to various
      functions, which makes invoking them hairy.  Each function knows
      which config options it is interested and could *probably* just
      extract these from aptcfg as appropriate.

    - if there are config options which are parsed in to a data
      structure, this can be handled in a similar fashion to apt-pkg's
      handling of, e.g., acquire::compressiontypes (see
      apt-pkg/aptconfiguration.cc)


Any thoughts on this?

I will look at tackling step i very soon.