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

[Daniel Hartwig]

On 16 November 2012 20:36, Axel Beckert <abe at debian.org> wrote:
> 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.

On a single system, possible, since you basically specify the complete
apt command line(s).  When trying to use a central config plus local
tweaks that is definitely not easy :-)

> 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 had somewhat imagined the setup you later describe, though with your
details I can easily see how a declarative syntax would also have to
be rather complex to handle that level of local-system overriding and
so on.

I once had a pipe dream of a declarative syntax that would support
default actions and package lists (like pkgsel's “make sure these are
installed, and these others are not”) with local overrides, and it
ended up looking a lot like apt_preferences :-/

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

I had assumed that pkgsync supported a similar run-parts type config,
allowing local overrides, etc..  But anyway, it can't do what you want
unless you can override the default to “upgrade all packages” with
“but not package X and Y on some host.”  (Also the inability to
control holds and such.)

Well I wish you gentlemen success.  It seems that you already have
quite a useful tool to work with.

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

Indeed.

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

If only it had a hook to run post-update and pre-clean …

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

Note that the dpkg options are ignored when aptitude tries “dpkg
--configure -a” to fix a failed install.

https://bugs.launchpad.net/bugs/257279

Regards