Debian Bug report logs - #71251
tmpreaper: why have we forked this package?

version graph

Package: tmpreaper; Maintainer for tmpreaper is Paul Slootman <paul@debian.org>; Source for tmpreaper is src:tmpreaper.

Reported by: Joey Hess <joeyh@debian.org>

Date: Sun, 10 Sep 2000 04:03:19 UTC

Severity: normal

Found in version 1.4.11

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Paul Slootman <paul@debian.org>:
Bug#71251; Package tmpreaper. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
New Bug report received and forwarded. Copy sent to Paul Slootman <paul@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: submit@bugs.debian.org
Subject: tmpreaper: why have we forked this package?
Date: Sat, 9 Sep 2000 20:52:37 -0700 (PDT)
Package: tmpreaper
Version: 1.4.11
Severity: normal

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.

 -- Karl M. Hegbloom <karlheg@inetarena.com>  Sun,  7 Dec 1997 13:42:03 -0800

This has galled me almost from the day it happened, and I'm finally going to
write a bug report. Of course, the maintainer has changed since 1997, and I
hope the new maintainer sees things differently..

If we forked away from upstream everytime they released a new upstream version
w/o patches we had sent them, parobably one quarter of the software in Debian
would be forked by now. It smells like an overreaction. As Debian developers,
we are expected to be able to work with the upstream developers of software.

Tmpwatch is still out there, still being actively developed. As I am about
to note in another bug report, it's recently had a security hole found in it,
and the fork of the program in Debian is vulnerable. It's really silly to 
fork a security related program. It puts you in a position of playing
catch-up. It doesn't benefit anyone.

Please un-do the fork; merge Debian's changes into tmpwatch, or if upstream 
will not have them, deal with that as a Debian developer is expected to do.

-- System Information
Debian Release: woody
Kernel Version: Linux kite 2.2.17 #1 Mon Sep 4 23:20:27 PDT 2000 i686 unknown

Versions of the packages tmpreaper depends on:
ii  libc6          2.1.3-10       GNU C Library: Shared libraries and Timezone



Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#71251; Package tmpreaper. Full text and rfc822 format available.

Acknowledgement sent to Paul Slootman <paul@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #10 received at 71251@bugs.debian.org (full text, mbox):

From: Paul Slootman <paul@debian.org>
To: Joey Hess <joey@kitenet.net>, 71251@bugs.debian.org
Subject: Re: Bug#71251: tmpreaper: why have we forked this package?
Date: Tue, 12 Sep 2000 14:54:10 +0200
On Sat 09 Sep 2000, Joey Hess wrote:

> This has galled me almost from the day it happened, and I'm finally going to
> write a bug report. Of course, the maintainer has changed since 1997, and I
> hope the new maintainer sees things differently..

I'm not basically averse to merging again...

> If we forked away from upstream everytime they released a new upstream version
> w/o patches we had sent them, parobably one quarter of the software in Debian
> would be forked by now. It smells like an overreaction. As Debian developers,
> we are expected to be able to work with the upstream developers of software.

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.

> Tmpwatch is still out there, still being actively developed. As I am about

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.

> to note in another bug report, it's recently had a security hole found in it,
> and the fork of the program in Debian is vulnerable. It's really silly to 
> fork a security related program. It puts you in a position of playing
> catch-up. It doesn't benefit anyone.
> 
> Please un-do the fork; merge Debian's changes into tmpwatch, or if upstream 
> will not have them, deal with that as a Debian developer is expected to do.

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
-- 
home:       paul@wurtel.demon.nl http://www.wurtel.demon.nl/
work:       paul@murphy.nl       http://www.murphy.nl/
debian:     paul@debian.org      http://www.debian.org/
isdn4linux: paul@isdn4linux.de   http://www.isdn4linux.de/



Information forwarded to debian-bugs-dist@lists.debian.org, Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org:
Bug#71251; Package tmpreaper. Full text and rfc822 format available.

Acknowledgement sent to pehasys@PlasmaLink.com:
Extra info received and forwarded to list. Copy sent to Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org. Full text and rfc822 format available.

Message #15 received at 71251@bugs.debian.org (full text, mbox):

From: pehasys@PlasmaLink.com
To: 71251@bugs.debian.org
Subject: tmpreaper better than tmpwatch without a doubt.
Date: Tue, 5 Feb 2002 15:51:37 -0800 (PST)
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.



Information forwarded to debian-bugs-dist@lists.debian.org, Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org:
Bug#71251; Package tmpreaper. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joeyh@debian.org>:
Extra info received and forwarded to list. Copy sent to Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org. Full text and rfc822 format available.

Message #20 received at 71251@bugs.debian.org (full text, mbox):

From: Joey Hess <joeyh@debian.org>
To: pehasys@PlasmaLink.com, 71251@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#71251: tmpreaper better than tmpwatch without a doubt.
Date: Tue, 5 Feb 2002 20:58:07 -0500
pehasys@PlasmaLink.com wrote:
> 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".

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.

-- 
see shy jo



Information forwarded to debian-bugs-dist@lists.debian.org, Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org:
Bug#71251; Package tmpreaper. Full text and rfc822 format available.

Acknowledgement sent to pehasys@PlasmaLink.com:
Extra info received and forwarded to list. Copy sent to Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org. Full text and rfc822 format available.

Message #25 received at 71251@bugs.debian.org (full text, mbox):

From: pehasys@PlasmaLink.com
To: Joey Hess <joeyh@debian.org>
Cc: 71251@bugs.debian.org
Subject: Re: Bug#71251: tmpreaper better than tmpwatch without a doubt.
Date: Tue, 5 Feb 2002 18:22:31 -0800 (PST)
> Which part of "forks are bad" don't you understand?

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.

> 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 don't see any features that tmpreaper has that tmpwatch doesn't. The
converse is, however, different.

> 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

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.

> a bug report. So pehasys@PlasmaLink.com, whoever you are.

...or you could just say Peter.

 - Peter.



Information forwarded to debian-bugs-dist@lists.debian.org, Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org:
Bug#71251; Package tmpreaper. Full text and rfc822 format available.

Acknowledgement sent to Joey Hess <joey@kitenet.net>:
Extra info received and forwarded to list. Copy sent to Paul Slootman <paul@debian.org>, tmpreaper@packages.qa.debian.org. Full text and rfc822 format available.

Message #30 received at 71251@bugs.debian.org (full text, mbox):

From: Joey Hess <joey@kitenet.net>
To: pehasys@PlasmaLink.com
Cc: 71251@bugs.debian.org
Subject: Re: Bug#71251: tmpreaper better than tmpwatch without a doubt.
Date: Tue, 5 Feb 2002 21:37:15 -0500
pehasys@PlasmaLink.com wrote:
> If the original is bad, doesn't accept patches and/or ignores suggestions,
> fork (or new path) is the only choice.

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

> 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.

It was not a rewrite though. See bug report.

-- 
see shy jo, who as an author has a certian amount of sympathy with
            someone who, presented with a giant patch that reindents
	    and gratuouously changes comments and stuff, in addition
	    to adding new features, rejects the patch. Heck, people like 
	    Linus are well on record of doing this all the time..



Changed Bug submitter from Joey Hess <joey@kitenet.net> to Joey Hess <joeyh@debian.org>. Request was from Joey Hess <joeyh@debian.org> to control@bugs.debian.org. Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 02:20:06 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.