On Mon, 23 Nov 2015 20:56:58 +0100 Marc Espie <[email protected]> wrote:

> On Mon, Nov 23, 2015 at 08:10:01PM +0200, [email protected] wrote:
> > 
> > You're right Marc, I found these, sorry for the noise (duh):
> >  
> > Nov 23 15:58:37 fire pkg_delete: Removed mcabber-0.10.3
> > Nov 23 15:58:38 fire pkg_delete: Removed desktop-file-utils-0.22p0
> > Nov 23 15:58:38 fire pkg_delete: Removed irssi-xmpp-0.52p2
> > Nov 23 15:58:40 fire pkg_delete: Removed loudmouth-1.4.3p6
> > Nov 23 15:58:44 fire pkg_delete: Removed irssi-otr-1.0.1
> > Nov 23 15:58:44 fire pkg_delete: Removed irssi-icb-0.14p10
> > Nov 23 15:58:53 fire pkg_delete: Removed irssi-0.8.16p0
> > Nov 23 15:59:38 fire pkg_delete: Removed glib2-2.46.1p0
> > Nov 23 16:00:01 fire newsyslog[4165]: logfile turned over
> > 
> > An unfortunate coincidence of log file turnover, less --follow-name
> > misuse and a forehead slapping moment.  Was getting kind of weary with
> > the python workarounds.
> >   
> To expand on this (answered quickly this morning): the idea with
> recent iterations of pkg_add/pkg_delete (with manual vs automatic
> installs) is to try to present the user with slightly less information
> (e.g., only the apps he's concerned about), so we hide various
> details such as pkg_delete -a "summary".

Got it, thanks and I concur on this.  I should have checked better
before asking and eliminate coincidence / uncertainties my end first.

> On the other hand, we do log everything, without any indication of
> 'why' a package got added or removed, as complementary information
> (allows you to simply log 'snapshots' of the state of your system,
> possibly usable by security scripts to check for anything funny).

That's the main reason behind me questioning it and the head scratching
moments.  My idea is to process the logs for state tracking, at least
observational purposes for now.

> In short, there's so much information actually computed inside the
> tools that it's quite difficult to figure out what to display and
> where...
> 
> 
> What you have is the best compromise at the moment.

Understood.  Thank you for the good high level explanation, appreciated.
I feel good about it.  The only comments I'll ever make related to pkg
tools is if there is some (any at all) ambiguity, and/or state tracking
consistency anyway, so don't expect to hear annoying stuff from me
anytime soon ;-)  I am a proponent of the idea of ability to feed status
data (logs etc), or any data / output produced for further processing
much in the Unix philosophy of interfacing programs.  Sorry for the
noise once again, thanks Marc.

Regards,
Anton

Reply via email to