tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: long-broken packages (some are removal candidates)



On 4/2/2012 21:06, Aleksej Saushev wrote:
It has _everything_ to do with usefulness. If it is useful, it should be
either fixed or left alone. It may just work for people who use it.

Sometimes it does take years to fix something. Some fixes are way more
involved than you think. All you can do with it then is staying aside and
watching, if you don't want to participate in heavy lifting or massive
code churn. That's why the pragmatic thing is to leave those packages alone,
if you personally cannot do anything.

One of recent examples is the story of fixing Octave. Your approach
would be to kill the package even if it just worked for some people due
to some unknown magic. OctaveForge package is another heavy lifting
which should be done nevertheless, if you want wider pkgsrc acceptance.
Your approach here is to remove it and thus reduce the value of NetBSD as
educational platform. I understand that you may care nothing of educational
packages, but then you shouldn't cramp others' efforts.


So twice now you've indicated pkgsrc acceptance/adoption, so it's clearly important to you. Here's my opinion on the best way to gain acceptance and wider adoption: Be high quality.

The following are examples of low quality in my opinion of any package system:
1) packages that are broken for unreasonably long time
2) packages that are years behind upstream releases
3) No apparent quality standards for the packaged software (e.g. lang/pnet, abandoned five years ago after a single alpha release) 4) Use of Kerberos 4, removed by every other package system after EOL and MIT (the author) said it was extremely insecure (security/kth-krb4, chat/zephyr, chat/tzc)
5) packages with distfiles that are unobtainable by new users


Leaving packages broken like a sore thumb works against wider adoption, not encourages it.
John



Home | Main Index | Thread Index | Old Index