DragonFly users List (threaded) for 2013-05
polling opinions: how much QT3/KDE3.5 to preserve in dports this July?
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
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