Date: Fri, 19 Aug 2011 21:47:33 -0700 From: perryh@pluto.rain.com To: utisoft@gmail.com Cc: mandree@freebsd.org, freebsd-ports@freebsd.org Subject: Re: sysutils/diskcheckd needs fixing and a maintainer Message-ID: <4e4f3c65.SWjpvhhzZjBepdJu%perryh@pluto.rain.com> In-Reply-To: <CADLo83-fu_B1S0Lcnypdhy%2BSe-stdmyBFVwHEinmyenBsLOfHQ@mail.gmail.com> References: <CADLo83-kEaQyFOiR45WmYdOru8vqu-MhAgb9p=OhjOo-TVUwfQ@mail.gmail.com> <201108171436.p7HEaNYQ071778@fire.js.berklix.net> <20110817161554.GA2496@lonesome.com> <4e4cc750.GqJImeHzdv6k8zld%perryh@pluto.rain.com> <CADLo83-MXGLOQexp9woAeSmKvC8rBobM49pidTBC7-eXTwoCZA@mail.gmail.com> <4E4CBBEE.4040302@FreeBSD.org> <CADLo83-fu_B1S0Lcnypdhy%2BSe-stdmyBFVwHEinmyenBsLOfHQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Rees <utisoft@gmail.com> wrote: > On 18 Aug 2011 08:15, "Matthias Andree" <mandree@freebsd.org> wrote: > > Am 18.08.2011 08:20, schrieb Chris Rees: > > > On 18 August 2011 09:03, <perryh@pluto.rain.com> wrote: > > >> Chris Rees <utisoft@gmail.com> wrote: > > >> > > >>> We don't want to provide broken software. > > >> > > >> Mark Linimon <linimon@lonesome.com> wrote: > > >> > > >>> ... it's obsolete, broken, junk ... > > >> > > >> Unless there is more to this than is reported in those two > > >> PRs, I'd call it a considerable exaggeration to describe > > >> diskcheckd as "broken". > > >> > > >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853 > > >> is shown as "closed", so presumably is no longer a problem. > > > > > > Wow, would it have been too difficult to actually READ the > > > closing message from Jeremy? I suggest you look again -- I've > > > pasted it here so you can see it. > > > > > > "The problem here is that the code does not do what the > > > manpage says (or vice-versa). The 3rd column does not specify > > > frequency of checking, but rather, over what duration of time > > > to spread a single disk scan over. Thus, 7 days would mean > > > "spread the entire disk check at X rate over the course of 7 > > > days" ... I'm closing the PR because trying to fix all of this > > > should really be ben@'s responsibility ... > > > > > > How does that indicate it's fixed? It's an 'abandoned' PR. If it's OK to close a PR without fixing it, because no one seems interested, maybe we should just close 143566 and be done with it :>-> The only "problem" I can see WRT 115853 is that someone misread the manpage. To me, it is clear that diskcheckd provides two _alternative_ ways of specifying how much bandwidth it should consume: diskcheckd.conf specifies either a length of time over which to spread each pass, or an average data rate. In either case it runs continuously, not intermittently. How else should one interpret the sentence "Naturally, it would be contradictory to specify both the frequency and the rate, so only one of these should be specified."? So it is correct that 115853 is "closed", because it wasn't valid in the first place. The program works as designed. > ... Let's get this straight, I was not 'attracting attention', > I was saying 'I'm going to remove this port; it's been broken > for over a year.' ... which might be justifiable, if it were in fact broken, but AFAICT it is not. I've been running it for a little less than two days now, on a drive which contains a gmirror, and have yet to see it misbehave. (The HDD indicator does stay on, but this is not surprising given that, as noted above, diskcheckd is expected to run continuously.) > > Do we need a "think twice before adding a port" habit? > > Yes. Of course, these aren't pointless ports however; while > still developed and maintained they were once useful. IIUC, diskcheckd started out in base and was later moved to ports (for reasons that are not obvious). I can't see that it is any less useful now than when first developed, or when moved from base to ports. > It's time to go when they break and bitrot. For some definition of "break and bitrot." Again, I haven't seen any actual breakage. diskcheckd could use a little tweaking, e.g. diskcheckd.conf.sample contains a stale reference to "the diskcheckd.conf(5) manual page" which was presumably missed when diskcheckd was moved to ports; it should now be "the diskcheckd(8) manual page". BTW how does one go about fixing a FreeBSD-native port like this? Since we are the upstream, it would make more sense to revise the distfile than to add a patch in the port. I didn't find any mention of this in the Porter's Handbook.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4e4f3c65.SWjpvhhzZjBepdJu%perryh>