[wpkg-users] [Bug 266] Feature: enhanced logging per package

[bugzilla-daemon at bugzilla.wpkg.org]

http://bugzilla.wpkg.org/show_bug.cgi?id=266

Rainer Meier <r.meier at wpkg.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |r.meier at wpkg.org
         Resolution|                            |WONTFIX

--- Comment #1 from Rainer Meier <r.meier at wpkg.org>  ---
I do not have any plans to implement such a feature. For me it's very prone to
errors and moreover it overlaps with existing WPKG functionality.

Some details:

WPKG 1.3.0 was heavily improved on reporting. Please have a close look at the
/query parameter. It allows you to analyze the current state of any client of
which you have the package database (wpkg.xml).

>From the request I understood you want to have better reporting on which
package is installed on certain clients (list of packages currently installed)
- or get a report of a package to see on which clients it's deployed.

For both queries there are tools which can do this using existing
functionality. You might want to have a look at wpkgCreateReport:
>http://wpkg.org/User_contributed_software#wpkgCreateReport>
It has been updated recently to support the new /query functionality of WPKG
1.3.0 and prepares a report of packages, in addition it shows graphical report
of pending updates/downgrades/removes in addition to current installation
state.



Additional notes.
I believe it does not make much sense to have clients running WPKG adding lines
to "marker" log files on the server. One of the problems you have already
indicated: Concurrent access. While it's unlikely to garble a file during
concurrent write with just a few clients the probability of issues increases
with number of clients if there is no transaction oriented concurrent access
middle-ware.
In addition WPKG internally does not distinguish updates from installs and you
will have multiple entries about a single client within these files.
In general I just think it's bad design to get the install state this way.
This does not mean you should get the install state from log files (which was
never the purpose of the log files either). Instead the local database
(wpkg.xml) represents precise state of the client. In order to know the install
state just copy wpkg.xml to a share where you can acceess it. There are
multiple ways to do this:

- Simply create wpkg-package which copies the file to a share
- If you use WPKG client you might use a post-execute command to
  copy wpkg.xml to a share
- You might allow wpkg to store wpkg.xml directly on a share
 (refer to config.xml)

Having a copy of wpkg.xml for each client on the server allows you to know
exactly what is currently really installed. Moreover you can even use wpkg.js
to analyze these logs which will also work in the future in case the structure
changes.


If you insist on having some logs when install commands are executed, then
there is also another option (not recommended though):
Just add another install/upgrade/downgrade/remove command to your package which
appends a line to your log file.

Something like
<install cmd='...' />
<install cmd='cmd /C echo Installation of package X finished >>
\\server\share\logs\package-X.log' />


This will simply append one line to the "package-X.log" file after all commands
have been executed. Due to the fact that WPKG stops execution of install
commands when they fail the line is only executed if all previous install
commands succeed.
Although there is one limitation: The install commands might be successful but
checks might still fail. So WPKG might still detect the software is not
installed properly but you get an entry in your log file. So I strongly
recommend to look for official interfaces and deal with "wpkg.xml".

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.