Hi, Daniel Hartwig wrote: > On 10 October 2012 23:02, Elmar S. Heeb <el...@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 <a...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org