On Fri, Jul 29, 2016 at 05:14:17PM +0200, Vincent Lefevre wrote:
> On 2016-07-29 16:17:33 +0200, Julian Andres Klode wrote:
> > Read the rest of the email. It's fairly obvious. This file contains
> > the latest scenario. You could argue that we should use a temporary
> > file name and then rename() to the final location instead of unlink()
> > + open(), but that also has the *huge* disadvantage of cluttering up
> > your file system if you're careless. Doing unlink() first is probably
> > a sane choice here, given that it's a log file logging exactly one
> > scenario, and not multiple one (that is, it stores no history).
>
> But, IMHO, this is not what is really documented in the apt-get(8)
> man page:
>
> -s, --simulate, --just-print, --dry-run, --recon, --no-act
> No action; perform a simulation of events that would occur based on
> ^^^^^^^^^
> the current system state but do not actually change the system.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> I think that log files are part of the system (they may contain
> important information on what occurred in the past). "No action"
> is not quite correct either since logs have been removed.
Your system isn't changed because packages aren't
removed/installed/upgraded, which is what -s means. If apt weren't
allowed to modify any file it couldn't create its cache for example and
you clearly don't want that not to happen – after all, you aren't
simulating the creation of the cache, you are simulating the
installation packages. We could dial that up to eleven and say that
system state is modified by opening any files already ("access time"),
but I hope you get the picture.
This log file has basically only one purpose: It can be attached to
bugreports so that a triager can reproduce the ordering problem a user
encounter. If the user encountered it in a simulation or not makes no
pratical difference and in fact, the subsystem involved here has no
knowledge about simulation or not for the exact same reason. It is
considerable easier to produce the same file after a simulation of
course as the state it records hasn't changed according to your requests
for real… until we realize that this could equally well be aptitude or
whatever else based on libapt where retracing your steps is slightly
harder than pressing up at the command prompt…
In so far it isn't the archetypical log file, but it seemed to fit best
in that category. I would dislike dropping such a file in /tmp or ~/
because it doesn't belong there even if there is precedence by other
tools. Its also not for state keeping (/var/lib) and not a cache
(/var/cache) as its never read. It does log the current state of the
system through which is why I placed it in /var/log. Its not ideal that
this is root-only, but as mentioned I really don't like ~/.
Do you have a better suggestion for a location?
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature