Dead projects in ports tree
Andrew W. Nosenko
andrew.w.nosenko at gmail.com
Tue Mar 3 02:10:22 PST 2009
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>
More information about the freebsd-ports