[Aptitude-devel] Fwd: Bug#690157: ITP: aptitude-robot -- Automate package choice management

Fri Nov 16 12:36:02 UTC 2012

Hi,

Daniel Hartwig wrote:
> On 10 October 2012 23:02, Elmar S. Heeb <elmar at heebs.ch> wrote:
> > Framework to use aptitude for automated package management including
> > upgrade, installation, removal, hold, etc.  Allows you to automate what
> > you would manually do with aptitude.
> 
> See also pkgsync, cron-apt, apticron.

We used cron-apt before for a long time. It just does upgrades or mail
about pending upgrades and as far as I know you can't tell them that
they should upgrade some packages and some not.

pkgsync is much closer to what we have in mind with aptitude-robot and
after looking at the source code, I must admit that the way it uses
aptitude is very close to ours. (From the description alone it looked
less like what we have in mind.)

> I note that the configuration is an imperative style: an explicit list
> of (aptitude-specific) actions to take.  I suspect that with a
> declarative config. (similar to pkgsync) there would be less
> unexpected side-effects.

Actually our first thoughts were even closer to pkgsync than we are
now.

> Clearly this program is simply meant as an automated interface to
> aptitude, although I think that most use cases would be covered by
> pkgsync if also supported list of packages to *not* upgrade.

As you noticed, the main difference to pkgsync is that aptitude-robot
allows to automatically upgrade most packages but to not automatically
upgrade some explicitly listed packages.

To make that easier with different sets of hosts or single hosts which
need indiviual changes we use run-parts to read in the package lists
from multiple, ordered files.

With this it's possible to distribute the base package list to
all hosts while other, more specific package lists will be distributed
only to a subset of the hosts. These package lists can override
entries in the base package list, especially they can prevent
automatic upgrades of a package on individual hosts while they get
automatically upgraded on most hosts.

The idea behind this is that while we can do fully automatic upgrades
on workstations, we want controlled upgrades of core services on
servers while automatic upgrading stuff like commandline utilities is
fine.

There are also cases where we want automatic upgrades of specific
server software one most hosts, but not on all. Common examples for
this are Apache and Postfix:

Postfix is installed on all our servers. Those which need postfix
just to send mails themselves have a simple default configuration and
postfix on them is not really critical. On the other hand, Postfix
also runs on our primary mail server and while its ok to automatically
upgrade commandline utilities on that box, we do not want automatic
upgrades of Postfix there.

Same situation with Apache: While Apache is installed on quite some
boxes to provide access to local statistic web pages or simple web
interfaces, it also runs on our primary webserver with several
hundered VHosts. We do not want automatic Apache upgrades there while
they're fine on other infrastructure servers.

There are some more differences, partially in the details:

* We allow both, holds and keeps to be configured.
* We allow both, purges and removes to be configured.
* We honour aptitude holds (ok, that would be trivial to implement
  in pkgsync, i.e. it's probably a bug in pkgsync that it doesn't
  honour holds. :-)
* aptitude-robot by itself allows questions to be presented on the
  commandline. Only aptitude-robot-session will silence those
  questions.

> Any comments on the distinction, and the particular novelties of
> your approach?

aptitude-robot should be as close as possible to the interactive use.
So, yes, it's on purpose rather imperative than declarative.
Essentially you should be able to "record" your interactive session
and write it down as configuration files for aptitude-robot.

> Any ideas how it could synchronize with the periodic apt script that
> performs update, clean, etc.?

>From our experience there is an inherent problem between multiple
tools handling automatic package list updates and package upgrades
stepping on each others toes. This is the main reason why we stopped
using cron-apt and disabled apt periodic in favour of aptitude-robot.

But our discussion about how to reply to this question just gave us
the idea that we may be able to run aptitude-robot triggered by apt
periodic. We'll investigate this idea.

> From aptitude-robot-session:
> 
> > # yes "" forces the default answer to any configuration question
> > nice yes "" | /usr/sbin/aptitude-robot
> 
> Have you considered something more explicit, such as:
> 
> # aptitude -y -o DPkg::Options::=--force-confdef \
>    -o DPkg::Options::=--force-confold …

Good point! Thanks.

> Though these options currently have problems when a package fails to
> install or remove.
> 
> From TODO:
> 
> > * allow package+ and package&M (or &m) to be both specified for the
> >   same package (currently the last one wins)
> 
> I guess you would combine these internally to “+M”?

Yes and no. See http://bugs.debian.org/693144

		Regards, Axel and Elmar
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5