[PATCH consfigurator] APT properties: cache packages installed or removed this deployment

[David Bremner]

Sean Whitton <spwhitton at spwhitton.name> writes:

> Hello,
>
> On Sat 05 Nov 2022 at 11:58AM -04, David Bremner wrote:
>>
>> As mentioned on IRC, I currently have one use-case for calling apt-get
>> directly, namely calling build-dep. I'm not sure if this is a problem or
>> not. If you have a clear idea of what breaks if the cache(s) get out of
>> sync, maybe it would be worth explaining.

I have finally got around to testing v3 of your patch on my hosts where
the build-dep property is used. No ill effects were detected.


> The caching is only to avoid running commands that we don't have to run.
> If it fails such that commands which we didn't have to run get run, then
> no harm is done.  There'd only be a problem if we didn't run a command
> that we in fact needed to run.
>
> Your build-dep thing installs a series of packages.  Suppose one is foo.
> Then if we have
>
>     (apt:removed "foo")
>     (bremner)
>     (apt:removed "foo")
>
> the second APT:REMOVED would do nothing, even though it was meant to.
>
> Is there a sequence like this which could actually be a problem?

If foo is installed by the build-dep, then the second apt:removed does
nothing, as you say, but foo remains installed. So if foo was removed so
as not to conflict with some other package "bar", then a following
(apt:installed "bar") would fail, somewhat surprisingly. This is fixable
with your new cache invalidation function, but

1) I still think the commentary "in a way that is significant to the
deployment" is a bit vague (maybe unavoidably?)

2) It might be nice to have a function/macro  apt:get  (or some other
name) that invalidates the cache, and document that as the way to run
arbitary apt-get commands. That could be a future enhancement,