Dead projects in ports tree

[Andrew W. Nosenko]

On Tue, Mar 3, 2009 at 10:26 AM, Garrett Cooper <yanefbsd at gmail.com> wrote:
> On Mon, Mar 2, 2009 at 3:34 PM, Paul Schmehl <pschmehl_lists at tx.rr.com> wrote:

>> I completely agree.  So long as a port is being used and people find it
>> useful, I think it would be a mistake to remove those ports.  In fact I
>> suspect it wouldn't be long before someone was submitting a PR to reinstate
>> the port. Perfect example is converters/unix2dos, last updated in 2003 and
>> converters/mpack, last updated in 2006.
>>
>> I still use both, and I would be irritated if they were removed from ports.
>>
>> A lack of development activity != a lack of usefulness
>
> I agree for projects like that that are feature complete.
>
> However, projects like xmms drag on the use of gtk 1.2 and will soon
> be out of date in terms of file formats, decoding capability, etc.
> Then again I suppose when that day comes xmms will be marked busted
> and eventually shuffled out of the tree, so I'll shut my trap about
> that :).

And what?  Until gtk+-1.2 removed from ports, the xmms perfectly able
to compile and run, at least from the gtk+ dependency side.  Anyone,
who don't like gtk-1.2 installed may just don't install both xmms and
gtk+-1.2, just like me.  Personal preferences are just personal
preferences and no more.

About file formats: my 5 years hardware dvd player also has limited
decoding capability and formats support in comparison with today ones,
but these capabilities are enough for me.  And it still work.  Now
question: why I need to replace it if all just works and fits my
requirements?  The same logic may be applied to software too: why
drop/replace if it just works?  When it xmms occur to be uncompiliable
or unable to run -- then yes, it may be reason to abandon it.  But
when it works ... see no reasons to remove.

Frankly, I would glad to see absolutelly another discussion: not about
dropping software that works (and as far as I understand, which port
is maintained), but about making needed but broken software work again
(e.g. valgrind, which is compiliable, but absolutelly not runnable
since freebsd-7.0, and unfortunatelly has no replacement...)

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>