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

[Sean Whitton]

Hello,

On Sun 27 Nov 2022 at 08:42PM -04, David Bremner wrote:

> Sean Whitton <spwhitton at spwhitton.name> writes:
>
>> 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".

This is helpful feedback, thank you.  I'll consider this a
consfig-breaking change, then.

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

I've put both in the comment in apt.lisp and something like your warning
in news.rst.  (I think we need some place in the manual to write general
remarks people should read before using a given package of properties.)

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

Your comments above have made me realise that I shouldn't be thinking
about just dpkg database manipulations.  For example, you might import
an existing shell script that installs or removes packages into your
consfig, because it's well-tested and you know what it does, and
Consfigurator shouldn't force you to have to rewrite it in terms of its
APT properties.

-- 
Sean Whitton