Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 10 Mar 2024 22:49:35 +0100
From:      Daniel Engberg <daniel.engberg.lists@pyret.net>
To:        Eugene Grosbein <eugen@grosbein.net>
Cc:        Florian Smeets <flo@FreeBSD.org>, ports@freebsd.org
Subject:   Re: Proposed ports deprecation and removal policy
Message-ID:  <c5e3e5d2d058d90777828b88a0f1506e@mail.infomaniak.com>
In-Reply-To: <1c5b7818-842f-f7b8-9d4e-5bf681cad20e@grosbein.net>
References:  <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> <1c5b7818-842f-f7b8-9d4e-5bf681cad20e@grosbein.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2024-03-10T21:45:16.000+01:00, Eugene Grosbein <eugen@grosbein.net> wrot=
e:
>  29.02.2024 2:22, Florian Smeets wrote:
>=20
>=20
> >    This policy should give some guidance on when ports can or should be=
 removed. In general ports should not be removed without reason but if a po=
rt blocks progress it should be deprecated and subsequently removed. In gen=
eral, if a ports blocks progress for some time it will be removed so that p=
rogress can be made. For more details see below.
> > =20
> > =20
> >  Ports can be removed immediately if one of the following conditions is=
 met:
> > =20
> >  - Upstream distfile is no longer available from the original source/mi=
rror
> >  (Our and other distcaches e.g. Debian, Gentoo, etc do not count as "av=
ailable")
> >  - Upstream WWW is unavailable: deprecate, remove after 3 months
> =20
> [skip]
>=20
>=20
> >    A port can be deprecated and subsequently removed if:
> > =20
> >  - Upstream declared the version EOL or officially stopped development.
> >  DEPRECATED should be set as soon as the planned removal date is know.
> =20
> Objection to quoted reasons. A software not developed anymore but still w=
orks fine
> after years is best software ever. Do not touch it, please.
>=20
> Some examples:
>=20
> mail/qpopper=09=09=09abadoned by Qualcomm years ago
> russian/d1489=09=09=09created by ache@ who passed away years ago
> net/quagga=09=09=09abadonware but still best OSPF implementation for Free=
BSD kernel
> net-im/pidgin-manualsize=09abadoned by initial author years ago
> databases/oracle8-client=09the only known library to link native FreeBSD =
code with for OracleDB connection
>=20
> Do not "fix" what ain't broken.
>=20
Eugene

I'm going to assume that there will be a PR or something regarding maintain=
ed ports either way.=20

In general not directed to the mentioned ports specifically but using a few=
 as examples,=20

As far as the "Do not "fix" what ain't broken" argument goes one major conc=
ern is how do you know especially regarding to Internet facing services? Qp=
opper (for example) has been dropped by pretty much every distro https://re=
pology.org/project/qpopper/versions and upstream is dead so there's no hub =
for communication. There likely aren't many eyes on the software by now (I =
guess for both good and bad reasons) but it might also very well bite you o=
r users in the end. That being said, all software contains bugs including a=
ctive projects so it's not like it's a clean cut in terms of security conce=
rns (wordpress) but you'll likely see issues being adressed and reported wh=
en software is more widely available. If upstream is dead it's very likely =
that security reports ends up in some package repo, random hosted fork or s=
uch and never finds it way outside of it.

Quagga is in a similar position, pfsense seems to point users to frr and th=
ere's also other software such as bird/bird2 .

According to https://www.orafaq.com/wiki/Oracle_8 Oracle 8 support ended 20=
 years ago, it's also marked as i386 only so its days are counted.

Nothing is stopping people to use an overlay but not everything needs to be=
 in or rather stay the "public" repo forever.

Best regards,
Daniel



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c5e3e5d2d058d90777828b88a0f1506e>