apt type should take flags for install

[mattly]

this breaks on vagrant:

ok apt iptables-persistent

Thanks to the crappy dialog thing that the iptables-persistent package brings up. There's apparently a flag for installing it without that dialog (still looking for this), but we'll need a way to pass it through.

[dhamidi]

The flag is called -y, see http://linux.die.net/man/8/apt-get (search for interactive)

[mattly]

Thanks; I had thought -y was synonymous with --yes (which I'm using), but I'll look at that. I had found another solution involving debconf that I should document too.

[dhamidi]

I had thought -y was synonymous with --yes (which I'm using)

It is synonymous with --yes, --assume-yes and the configuration item APT::GET::Assume-Yes.

From the link:

-y, --yes, --assume-yes
Automatic yes to prompts. Assume "yes" as answer to all prompts and run non-interactively. If an
undesirable situation, such as changing a held package or removing an essential package, occurs
then apt-get will abort.
Configuration Item: APT::Get::Assume-Yes.

I hope that helps to clear up the confusion.

[frdmn]

As far as I know is the -y just for boolean interactions like confirmations prompts. But whenever the package asks for strings as user input, you have to pass those via debconf-set-selections to bypass the interactive dialog. Here's an example from a Vagrant bootstrap file: https://gist.github.com/rrosiek/8190550#file-install_mysql-sh-L26-L33

You can use debconf-get-selections to list available configurations for a certain package (postfix in the following example):

root@obi-wan ~ $ apt-get install debconf-utils
root@obi-wan ~ $ grep -C1 postfix /var/cache/debconf/config.dat

Name: postfix/bad_recipient_delimiter
Template: postfix/bad_recipient_delimiter
Owners: postfix

Name: postfix/chattr
Template: postfix/chattr
Owners: postfix

Name: postfix/destinations
Template: postfix/destinations
Value: obi-wan.yeahwh.at, localhost.yeahwh.at, localhost
Owners: postfix
Flags: set
[...]

This means, I'm not sure if we can fix this issue at all unless bork has a way to pass those dpkconf defaults.

[mattly]

hm... I think what we need is some use cases, shell scripts to pass those cases, and then an idealized form of what those would look like in bork.