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?
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2WFFXOADWUGQCDCEMLXBH
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.=
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 gi=
ve
>> an idea how aggressive FreeBSD is with maintaining the currency of the=
ir
>> 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=
g
>> (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=
s
>> is not a particularly popular decision with FreeBSD users and there ha=
s
>> 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=
ot
>> of ports.
>> 2) "Lock in" the core KDE 3.5 ports (everything pulled in by KDE3.5 me=
ta
>> 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=
e.
>> 2) These are numerous ports, they could number over 100, so it's pushi=
ng
>> 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=
e
>> 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=
ly
>> relish the idea of maintaining it alone. Perhaps somebody that really=
>> wants these packages would take responsibility for them if we keep the=
m
>> beyond July?
>=20
> 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=
R1NwNTNwWUxReHdOanc&usp=3Dsharing
>=20
>=20
> 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.
>=20
> After going through this exercise, I dread even the exercising of
> "locking" them in dports so they don't disappear when FreeBSD prunes th=
em.
>=20
> 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.
>=20
> 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=
e
> any ports that are critical in some way bring it up.
>=20
> I just think we don't have enough manpower on dports to maintain this
> over time.
>=20
> John
>=20
--=20
Please use PGP to encrypt your email to ensure our privacy is respected.
------enig2WFFXOADWUGQCDCEMLXBH
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/
iQEcBAEBAgAGBQJRzMpQAAoJELm0ZwAmGwI5V2UH/2eKGtrTez6LwiiVzX7vGLrf
PW18fuBJialweLBPsj3zvjE97Jn5APgMnFN6lie+ztprWVhL5xBVcpVm/3wXDlOz
2hf1oxO5R6rqT/1tJSpaS/Ib7voeiIRT2CJ4GdWNgz5Kg/VpSKf3h9Un0TDSyKZc
pO/bcg2RLtqefkPxqfM0Hi8S5HaNN9wup9cEG9FwXLjkJ/3MuAHpjoGQtLzfF2L6
RIAFzKz56e4w7TCjLE+rzD6K1rw1IK6aSQ9Y1zeQZy2VnXEMfiE7OPNTyalG3ZfG
rrGaKxZYV9hAodg3z+kj2ehq/8z0xkorrqobpG/sZKoBHpP/QG3srLc1O0NSUi4=
=EUaG
-----END PGP SIGNATURE-----
------enig2WFFXOADWUGQCDCEMLXBH--
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]