I think we should start discussing what we do with these remaining ones. obache already suggested that we remove some of them (and I agree). What about the rest? (I'm aware of wip/fvwm-themes.) It seems like the number is dropping fairly rapidly, but perhaps it's hitting a plateau. As I have said before, we should be asking if our proposed removals are in the interest of pkgsrc users, not removing things because we don't like them - and the entire "non-DESTDIR packages should be removed" process has always seemed not entirely connected with an evaluation of user interests. I think two steps are appropriate: 1) For each package, if it is a candidate for removal because a) it is unmaintained or obsolete upstream and b) is so old that we can't imagine that anyone is using, propose removal using the normal "crufty package removal process", whatever that is this week. 2) Beyond 1, we are left with packages that don't merit removal other than because of DESTDIR. I suspect many of them need updates (ghc, darcs certainly do). The benefit to pkgsrc maintenance (and thus to users) comes from removing support for the non-DESTDIR installation path, not from removing the control files from CVS. So changing the mk files to not fallback to DESTDIR would get us 99% of the benefit. Leaving the control files will make it significantly easier for someone to resurrect the package (probably with an upgrade). I don't think it makes sense to remove packages soley because of non-DESTDIR unless we first decide to withdraw the ability to build non-DESTDIR packages. I also haven't seen any (recent/pending) proposed infrastructure changes with an analysis that dropping non-DESTDIR support makes the changes easier/cleaner. So while I believe that removing non-DESTDIR support eventually is appropriate, there is no pressing need. When that happens, we have a clear tradeoff.
Attachment:
pgp0UGlDxk0Hd.pgp
Description: PGP signature