Re: Proposed ports deprecation and removal policy

From: Daniel Engberg <daniel.engberg.lists_at_pyret.net>
Date: Sun, 10 Mar 2024 21:49:35 UTC
On 2024-03-10T21:45:16.000+01:00, Eugene Grosbein <eugen@grosbein.net> wrote:
>  29.02.2024 2:22, Florian Smeets wrote:
> 
> 
> >    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 port blocks progress it should be deprecated and subsequently removed. In general, if a ports blocks progress for some time it will be removed so that progress can be made. For more details see below.
> >  
> >  
> >  Ports can be removed immediately if one of the following conditions is met:
> >  
> >  - Upstream distfile is no longer available from the original source/mirror
> >  (Our and other distcaches e.g. Debian, Gentoo, etc do not count as "available")
> >  - Upstream WWW is unavailable: deprecate, remove after 3 months
>  
> [skip]
> 
> 
> >    A port can be deprecated and subsequently removed if:
> >  
> >  - Upstream declared the version EOL or officially stopped development.
> >  DEPRECATED should be set as soon as the planned removal date is know.
>  
> Objection to quoted reasons. A software not developed anymore but still works fine
> after years is best software ever. Do not touch it, please.
> 
> Some examples:
> 
> mail/qpopper			abadoned by Qualcomm years ago
> russian/d1489			created by ache@ who passed away years ago
> net/quagga			abadonware but still best OSPF implementation for FreeBSD kernel
> net-im/pidgin-manualsize	abadoned by initial author years ago
> databases/oracle8-client	the only known library to link native FreeBSD code with for OracleDB connection
> 
> Do not "fix" what ain't broken.
> 
Eugene

I'm going to assume that there will be a PR or something regarding maintained ports either way. 

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

As far as the "Do not "fix" what ain't broken" argument goes one major concern is how do you know especially regarding to Internet facing services? Qpopper (for example) has been dropped by pretty much every distro https://repology.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 or users in the end. That being said, all software contains bugs including active projects so it's not like it's a clean cut in terms of security concerns (wordpress) but you'll likely see issues being adressed and reported when 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 such and never finds it way outside of it.

Quagga is in a similar position, pfsense seems to point users to frr and there'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