Re: Proposed ports deprecation and removal policy

11.03.2024 4:49, Daniel Engberg wrote:

>>>  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.

I maintain most of listed ports.

> 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?

Not every port deals with public Internet and services therein.

> 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.

And not need to, practice shows.

> 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.

Until then, it works and let it be.

> That being said, all software contains bugs

True. The question is, do any of bugs affect particular setup? If not, let it be.

> 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.

There are private networks not exposed to untrusted users or hosts not affected by any security concerns,
including one-user-only. No need to break their setups.

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

frr development is Linux-centric and its OSPF implementation has some problems under FreeBSD ignored by developers,
it cannot be a replacement (can't tell for bird/bird2). Quagga ospfd/bgpd work fine, let it be.

> 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.

This is userland library and we have no plans to eliminate userland i386 support yet.
No alternatives, also.

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

Not forever. While it works fine.

Eugene