FreeBSD ports which are currently scheduled for deletion

Kevin Oberman rkoberman at gmail.com
Wed Apr 9 05:33:28 UTC 2014


On Tue, Apr 8, 2014 at 3:20 PM, Tijl Coosemans <tijl at coosemans.org> wrote:

> On Tue, 08 Apr 2014 13:12:48 -0400 Mikhail T. wrote:
> > On 08.04.2014 12:55, Tijl Coosemans wrote:
> >> On Tue, 08 Apr 2014 09:57:48 -0400 Mikhail T. wrote:
> >>> On 08.04.2014 08:00, freebsd-ports-request at freebsd.org wrote:
> >>>> If people are using a port, then I would agree it should be kept
> >>>> regardless of maintainer status. But that doesn't mean keeping
> >>>> everything forever as long as it compiles.
> >>> Why not? Why not "keep everything forever as long as it compiles"?
> Where
> >>> is this idea coming from, that stuff must be continuously updated to be
> >>> considered usable?
> >> It doesn't have to be updated continuously, but it has to be used.
> >> Keeping a port requires effort.  It needs to be kept up to date with
> >> infrastructural changes (like staging) and if nobody is using the port
> >> that's just a waste of effort.
> > Tijl, there is no indication whatsoever, that ports on the chopping
> block are
> > not used. The argument put forth by the proponents of the removals is
> thus: "The
> > upstream authors haven't made a new release in a long time, therefor the
> > software must be neither any good, nor see much use."
> >
> > I find this logic flawed -- some of my favorite books are more than 2000
> years
> > old, for example... Their authors certainly aren't making new releases,
> yet they
> > continue to be maintained, built (published), and used by generations.
> >
> > The closest we've ever come to estimating usage is the following: "If
> there is
> > any user-base to speak of, then there should be a person among them
> willing to
> > maintain the port -- or pay someone to maintain it." This, too, is
> flawed in my
> > opinion -- expecting a graphics-artist, a biologist, or an audiophile to
> also be
> > a half-decent software engineer is a stretch; expecting them to pay for
> > port-maintainership is also not fair, when the entire OS is free, done
> for fun,
> > rather than profit.
> >
> > Though I agree, that unmaintained ports should be dropped when they
> break due to
> > things like security bugs or compiler-upgrades, the self-inflicted
> wounds like
> > infrastructure changes do not qualify. Volunteers taking it upon
> themselves to
> > perform such changes, should be prepared to deal with all that's
> required for them.
>
> Volunteer time should not be wasted on ports nobody uses.  Removing such
> ports is a good thing.
>
> It's impossible to prove that a port is really unused, but if there are
> enough indications that it is potentially unused it becomes reasonable to
> assume that it is.  Lack of upstream development is one such indicator
> and by itself it may not be enough but in the examples you've given it
> isn't the only indicator.  For qvplay for instance the main argument is
> that it is support software for a 250 kilopixel camera from the nineties.
> For xmms there's xmms2, audacious and numerous other multimedia players.
>

Happily, a fix for xmms is in the offing. But you should realize that xmms2
is in no way a replacement for xmms, though the authors seemed to have
believed that it was.  Instead it is a needlessly complex client/server
system for playing  audio files. I'm sure that someone found xmms2 useful,
but for simply playing music, it is both overkill and complex to use.
Besides, DLNA has made it pretty obsolete as a media server.

If a port, say xmms, is believed obsolete, deprecation with a revision bump
so people who use it see that it was deprecated, I think you would hear if
you happened to be wrong about how obsolete it is.. :-) I that how it is
being done? If it is marked AND revision bumped, it is much more likely
that you will find out that a port is still being used BEFORE it is
removed. (I don't know whether or not this is the procedure.)
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman at gmail.com


More information about the freebsd-ports mailing list