http://bugzilla.wpkg.org/show_bug.cgi?id=92
Rainer Meier <[EMAIL PROTECTED]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[EMAIL PROTECTED]
| |t
--- Comment #26 from Rainer Meier <[EMAIL PROTECTED]> 2008-01-08 23:57:31 ---
#12:
This is fine and related to the update before remove functionality which allows
the system administrator to provide an updated version of the package which
removes properly before the package uninstall commands are executed.
Well, this causes the install procedure to be entered even if there is NO new
package on the server. This is due to the fact that I dramatically improved the
installPackage() function which will detect by itself if the package is to be
installed, to be upgraded or not to be touched at all. So an installation will
be attempted in any case!
-----
In general I still do not support having multiple log-levels at all. It is
simply not maintainable in the future. I am not going to list up all arguments
again but in short...
As long as there are no _strict_ rules to be followed we will always have the
same discussion. Some people would like to have some debug messages in
debug-level 1, some in debug-level 2 and we could discuss forever about it.
Finally this leads to the fact that almost each message needs its own debug
level so you have full flexibility which messages to be shown and which ones to
be suppressed. I see that dinfo, sinfo, cinfo and pinfo has been created. I am
absolutely SURE that not all debug messages fit this scheme and for each new
message I would have to decide which log level it applies to. Debug messages
are for DEBUGGING, not for productive operation. Success, error and warnings
are perfectly fine for productive operation. It's recommended to use debug
logging only on testbed or on selected pilot-phase machines.
Additionally I repeat myself once again. If I need to debug and really to trace
execution to find a bug in WPKG then I want to have FULL AND UNLIMITED debug.
So I will anyway set it to the highest possible debug level. Nobody will ever
try to trace a bug with "medium-debugging"; chances that exactly THE important
message is hidden are too high.
I feel supported by this thread here where even this few people have problems
to fully agree what level of detail should be printed on which log level.
If I look for some specific messages within the log - or if I want to hide some
lines - I use 'grep' or 'grep -v'. Period.
I am fine if this modification is included as a patch within the WPKG
deployment package but I will not support it and I will not include it directly
within "my" releases. I simply think if we are going this direction WPKG will
be unmaintainable very soon. I hope you can understand this. I really wouldn't
like to see WPKG forks just because of the logging issue. Flexibility is a nice
thing but to a certain extent I have to agree to our OSS colleagues at the
Pidgin project where I also had a hard discussion about "featuritis" and
"maintainability" (well at that time I supported the opposite opinion but I
have to admit that they were partially right.
--
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
Easy Software Deployment >> http://wpkg.org
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
