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

Daniel Hartwig mandyke at gmail.com
Fri Nov 16 03:31:59 UTC 2012


---------- Forwarded message ----------
From: Daniel Hartwig <mandyke at gmail.com>
Date: 16 November 2012 11:31
Subject: Re: Bug#690157: ITP: aptitude-robot -- Automate package
choice management
To: "Elmar S. Heeb" <elmar at heebs.ch>, 690157 at bugs.debian.org,
aptitude-devel at lists.alitoh.debian.org


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.

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.  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.

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

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

>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 …

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”?

Regards



More information about the Aptitude-devel mailing list