polling opinions: how much QT3/KDE3.5 to preserve in dports this July?

[John Marino <dragonflybsd@xxxxxxxxx>]

There are DragonFly-only dports, and in a few cases there are dports 
that used to be in FreeBSD but have since been deleted.  Normally I 
"purge" these dports soon after, although occasionally I keep them (e.g. 
libusb v0.1 which is needed for legacy usb support).  I've already 
purged a couple of hundred dports from the repository, which should give 
an idea how aggressive FreeBSD is with maintaining the currency of their 
ports.  With 24,000+ ports, this constant pruning is necessary and welcome.

There's a decision to be made though.  At the beginning of the year, 
FreeBSD made the decision to purge all ports depending on QT3 including 
(and especially) KDE3.5 which runs pretty well on DragonFly.  They go 
EOL on 1 July, which means they'll probably be purged that month.  This 
is not a particularly popular decision with FreeBSD users and there has 
been push-back, but I think this purging will occur as planned.

We've got three options:
1) Follow suit and purge all these QT3 and KDE 3.5 ports.  This is a lot 
of ports.
2) "Lock in" the core KDE 3.5 ports (everything pulled in by KDE3.5 meta 
package) but let the other ports go.
3) "Lock in" everything (don't purge any QT3 or KDE 3.5 ports).

There are a few drawbacks to keeping these when FreeBSD doesn't.
1) obviously they are static and they will break in time.  Either the 
ports infrastructure will change or newer compilers which are stricter 
stop building them.  Or dependencies get upgraded and aren't compatible.
2) These are numerous ports, they could number over 100, so it's pushing 
the burden on maintenance back on us
3) They are being purged by FreeBSD mainly for security reasons 
(security flaws aren't patched as they aren't maintained upstream).  We 
would be perpetuating these (known) security flaws.

It's easy to say, "keep them all".  That does put a lot of work on us -- 
first to "lock them in" and then to maintain them.  With that in mind, 
which approach should be taken by DragonFly?  KDE3, which is much 
lighter than KDE4, is still a relative behemoth and I don't particularly 
relish the idea of maintaining it alone.  Perhaps somebody that really 
wants these packages would take responsibility for them if we keep them 
beyond July?

John