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

[David Bremner]

Sean Whitton <spwhitton at spwhitton.name> writes:


>>> 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
>
> Right.  The only question is whether it's realistic for something like
> this to happen.  If we're not sure, we can just assume that it could
> happen.

I think that depends if people are really calling apt directly (and
installing or removing packages via those calls).  If so, I would
imagine that many strange combinations can occur, precisely because the
encapsulation of operations inside properties makes it easier to forget
exactly what is going on. At least that was my unscientific impression
from using propellor naiveté turned to 11. On the other hand I would
consider the problem addressed by by a warning that said "if you install
or remove packages by calling apt or dpkg directly, make sure you
invalidate the cache".

>
>> 1) I still think the commentary "in a way that is significant to the
>> deployment" is a bit vague (maybe unavoidably?)
>
> Fair.  How is "in a way that could invalidate the assumptions made by
> implementations of properties subsequently to be applied"?

Better, but still a bit abstract. What do you think of my warning above?

>> 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,
>
> I think that this might be useful only for 'apt-get build-dep', and
> ideally we will add a property for that subcommand at some point?  I
> can't see any other apt-get(8) subcommands for which it might be useful
> that aren't already covered by properties.  The manual manipulation of
> the set of installed packages that I was envisaging was custom
> properties that invoke dpkg commands and/or manually manipulate its
> database.

Hmm. OK, there I'm maybe the wrong person to ask, as these days I never
install or remove packages with dpkg, even for testing. I never even
considered manually manipulating the dpkg database. I take your point
about the macro. I imagine people manually manipulating dpkg's database
can also infer that they should invalidate the consfigurator cache. But
maybe this kind of thing is more common than I think?