DragonFly BSD
DragonFly users List (threaded) for 2013-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

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

From: Petr Janda <elekktretterr@xxxxxxxxxxxxxx>
Date: Fri, 28 Jun 2013 09:27:10 +1000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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
>> 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 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:
> https://docs.google.com/spreadsheet/ccc?key=3D0AmOIvwOJYx_rdGNNeTV0cFRh=
> 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.
> John

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"

Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]