Re: Proposed ports deprecation and removal policy

On 2024-03-10 14:49, Daniel Engberg wrote:
> 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.
I'm going to suggest that this is a bit of a non-starter. Indeed as you say, 
all software
may have (security) issues. wordpress, as you mention, is used by the FBSD 
Foundation.
Windows requires a patch-of-the-day subscription. But there are *many* ports 
that are
trivial utilitarian ports that are highly unlikely to be of any consistence, 
and those
that do, would/should be under the purview of their respective maintainers. I 
would submit
that it is the responsibility of the maintainer to ensure their continued 
maintenance -- safety,
functionality, and availability. What is the responsibility of the 
maintainer, if not to
maintain the port?

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

-- 
--Chris Hutchinson