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

[John Marino]

On 5/31/2013 15:21, John Marino wrote:
> 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?

This reply is to the original post.
July is upon us and now it's decision time.
I have put all the affected ports in a spreadsheet:
https://docs.google.com/spreadsheet/ccc?key=0AmOIvwOJYx_rdGNNeTV0cFRhR1NwNTNwWUxReHdOanc&usp=sharing

This took me several hours to compile.  There are over 250 ports that 
use QT3, including everything KDE3.  I was mildly aggressive about 
purging ports but it looks like ~80 ports.  That leaves over 170 ports 
left for us to maintain without FreeBSD.  This is a big deal because 
ports suffer from bitrot a lot.

After going through this exercise, I dread even the exercising of 
"locking" them in dports so they don't disappear when FreeBSD prunes them.

Frankly, based on the amount of work it will cost us (and by us, I'm 
been 95%+ will fall to me), I am now recommending that we just cut KDE3 
and all the QT33 ports when FreeBSD does it.  It's a shame because it 
cost a lot of work to get them building, but I don't want to waste any 
more resources on this to conserve what was already spent.

Take a look at the list of ports on the kill list on the google docs 
spread sheet.  Anyone should be able to "comment" on the sheet but not 
change anything, e.g. to challenge purge or recommend purge.  If the are 
any ports that are critical in some way bring it up.

I just think we don't have enough manpower on dports to maintain this 
over time.

John