Re: CVS commit: pkgsrc/chat/jabberd

[Greg Troxel <gdt%lexort.com@localhost>]

Leonardo Taccari <leot%NetBSD.org@localhost> writes:

> Greg Troxel writes:
>> [...]
>> Log Message:
>> chat/jabberd: Note that it is ancient and unmaintained.
>> [...]
>
> In these cases we usually add an entry to pkg-vulnerabilites and
> eol-packages (the biggest advantage in doing that - unlike DESCR - is
> that the user is informed via `pkg_admin audit*' or similar).

A good point that pkg-vulnerabilites should have an eol entry.

> Is there a particular reason that this note should be present in DESCR
> or could that be moved to pkg-vulnerabilities and eol-packages
> instead?

Added to pkg-vulnerablites/eol-packages -- sure, that should be done.  I
have just done so.

But "moved", that is not reasonable.  DESCR is supposed to explain to
humans what is in the package, so that they can decide if they want to
install it.  The word "jabberd" describes two distinct pieces of
software that turn out to be not related, and the other is still sort of
maintained :-)

I don't think it serves users well to read a description that makes it
sound like software is useful and reasonable to run, install and
configure it, and then get an audit-packages mail about it.  (Yes, I
know you think they'll get a warning when installing it, but really,
they won't, because they will have set ALLOW_VULNERABLE_PACKAGES.)

I'm guessing that for you, the big thing is to add packages
eol-packages, not to remove such notes from DESCR.



On this subject, eol-packages is ambiguous on a few points:

  There is a date field.  What's this for, and what does it mean?

    - Is it the date the entry was added?  (If so, why is this useful?)

    - Is it the date that the package was declared eol by the upstream?

    - Is it the date that we decided, perhaps in retrospect, that
      upstream is no longer functioning?  If so, is there a norm for how
      and when to decide.  (Clearly 12 years is enough; it's 4 that's
      hard.)

  There is a "URL" field.  It's clear in the case of a functioning
  upstream that deprecates a branch, for which we have a multi-version
  package.  For an upstream that just sort of stops, it's quite unclear
  what if anything belongs here.


Comments at the beginning would be helpful.