sysutils/diskcheckd needs fixing and a maintainer

[perryh at pluto.rain.com]

Chris Rees <utisoft at gmail.com> wrote:
> On 18 Aug 2011 08:15, "Matthias Andree" <mandree at freebsd.org> wrote:
> > Am 18.08.2011 08:20, schrieb Chris Rees:
> > > On 18 August 2011 09:03,  <perryh at pluto.rain.com> wrote:
> > >> Chris Rees <utisoft at gmail.com> wrote:
> > >>
> > >>> We don't want to provide broken software.
> > >>
> > >> Mark Linimon <linimon at 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.