On 16 November 2012 20:36, Axel Beckert 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
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAN3veRfuzjnjMxqUQ3jnBq6mmoNwOUSGxJAMKxRZ+=nrg-e...@mail.gmail.com
