[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