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

[Petr Janda]

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
>> 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
> 


-- 
Please use PGP to encrypt your email to ensure our privacy is respected.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20130628/625c2609/attachment-0020.bin>