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

[Amitai Schlair <schmonz%schmonz.com@localhost>]

On Mon, Apr 2, 2012 at 3:18 PM, Jörn Clausen <joernc%googlemail.com@localhost> 
wrote:

> Is the transition from wip to pkgsrc a one-way road? How about moving
> those packages back to wip?

I think this is a great idea that can get us un-stuck. Thanks for suggesting it.

We all agree that we have limited developer-time that we can't afford
to waste. We all agree that broken packages hurt users and should be
minimized. We may not all agree that minimizing package breakage is a
function of well-directed developer effort. In the short term,
deliberately breaking some packages because they run afoul of some new
rule sounds counterproductive. But that may not be true in the long
term.

The new rule under discussion (and not for the first time --
http://mail-index.netbsd.org/pkgsrc-users/2011/04/07/msg014168.html is
my post in the last iteration) is that packages still not supporting
DESTDIR by now ought to be considered broken. On the face of it, that
breaks some packages for users and sounds counterproductive. But there
are benefits to users and to developers (and thus again to users) of
making pkgsrc DESTDIR-only.

A team with our constraints (and sense of taste) must always be
thinking of the long term. How maintainable is X? Will people
understand Y? Will developers be willing to do Z? Breaking packages
repels users, and that's a fair long-term concern. Combinatorically
complicating package-maintainers' lives repels developers, and that's
a long-term concern too. If it turns out that we can't have it both
ways, then we have to choose the one that costs less.

But relocating the packages in question to pkgsrc-wip sure looks like
it lets us have it both ways.

Can someone kindly recapitulate how our pkgsrc lives change if DESTDIR
support becomes mandatory? The costs and benefits been explained
before and I remember on balance finding them compelling.

Thanks,

- Amitai