tmpreaper (1.4.1-1) unstable; urgency=low
* Renaming from `tmpwatch' to `tmpreaper' to split away from RedHat, who
released a `tmpwatch-1.4' that had zero of the patches I sent them.
I'm not basically averse to merging again... Both sides need to cooperate for this to work, of course. Besides, forked software is responsible for a lot of great things; we wouldn't have vim but still have just elvis, for example. The "actively developed" part is a little doubtful IMHO. However, it seems to have a different upstream maintainer than at the time of the fork, so that might help. The programs are currently significantly different to make this a non-trivial task. Do a diff sometime; you will see that the debian source has also been cleaned up a lot (style has been standardised somewhat, comments have been added, C++-style comments replaced, etc) so (a) the job of merging back changes is harder, (b) the result is a lot less readable. Of course, if you want to make the effort of merging the debian changes back into tmpwatch, you're welcome to adopt tmpreaper / tmpwatch... I adopted it because no one else wanted it back then. Thanks, Paul Slootman
Even in Red Hat 7.2, tmpwatch doesn't delete directories. I suggest to close this bug report. If not, then at least mark it "wontfix". - Peter.
pehasys@PlasmaLink.com wrote: Which part of "forks are bad" don't you understand? Wouldn't it be nice if tmpwatch in redhat 7.2 had all the nice features that are in tmpwatch (er, excuse me, tmpreaper) in debian unstable? Wouldn't it be nice if the converse were also true? I stand by every word of my original bug report. I realize that the fact that Karl Hegbloom reformats every code-base he touches has left Paul Slootman in a bit of a bind WRT merging the two codebases, but "it's hard" is not a valid reason to call for the closure of a bug report. So pehasys@PlasmaLink.com, whoever you are.
If the original is bad, doesn't accept patches and/or ignores suggestions, fork (or new path) is the only choice. I have no information on what happened from the above in tmpreaper (er, excuse me, tmpwatch) case, I suspect that rewrite was just plain simpler. I don't see any features that tmpreaper has that tmpwatch doesn't. The converse is, however, different. It's not hard. It's just that patch is twice as big as the original .tar.gz (kill original code, generate new code). Pointless. ...or you could just say Peter. - Peter.
pehasys@PlasmaLink.com wrote: It's not the only choice though. See original bug report. It was not a rewrite though. See bug report.