polling opinions: how much QT3/KDE3.5 to preserve in dports this July?
elekktretterr at exemail.com.au
Thu Jun 27 16:27:10 PDT 2013
Would it be possible to keep them as statically-linked binaries? Maybe
we don't need to keep the ports them selves.
On 27/06/2013 10:48 PM, John Marino wrote:
> 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
>> 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:
> 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.
Please use PGP to encrypt your email to ensure our privacy is respected.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 553 bytes
Desc: OpenPGP digital signature
More information about the Users