#71251 tmpreaper: why have we forked this package?

Package:
tmpreaper
Source:
tmpreaper
Description:
cleans up files in directories based on their age
Submitter:
Joey Hess
Date:
2025-01-27 00:09:02 UTC
Severity:
normal
#71251#5
Date:
2000-09-10 03:52:37 UTC
From:
To:
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.

#71251#10
Date:
2000-09-12 12:54:10 UTC
From:
To:
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

#71251#15
Date:
2002-02-05 23:51:37 UTC
From:
To:
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.

#71251#20
Date:
2002-02-06 01:58:07 UTC
From:
To:
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.

#71251#25
Date:
2002-02-06 02:22:31 UTC
From:
To:
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.

#71251#30
Date:
2002-02-06 02:37:15 UTC
From:
To:
pehasys@PlasmaLink.com wrote:

It's not the only choice though. See original bug report.

It was not a rewrite though. See bug report.