DragonFly users List (threaded) for 2013-06
Re: polling opinions: how much QT3/KDE3.5 to preserve in dports this July?
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
Content-Type: text/plain; charset=ISO-8859-1
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.=
>> libusb v0.1 which is needed for legacy usb support). I've already
>> purged a couple of hundred dports from the repository, which should gi=
>> an idea how aggressive FreeBSD is with maintaining the currency of the=
>> 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 includin=
>> (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. Thi=
>> is not a particularly popular decision with FreeBSD users and there ha=
>> 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 l=
>> of ports.
>> 2) "Lock in" the core KDE 3.5 ports (everything pulled in by KDE3.5 me=
>> 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 compatibl=
>> 2) These are numerous ports, they could number over 100, so it's pushi=
>> 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). W=
>> 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 particular=
>> relish the idea of maintaining it alone. Perhaps somebody that really=
>> wants these packages would take responsibility for them if we keep the=
>> 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 th=
> 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 ar=
> 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.
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----