From nobody Mon Mar 11 02:11:20 2024 X-Original-To: ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TtKym60Ybz5DPyM for ; Mon, 11 Mar 2024 02:11:44 +0000 (UTC) (envelope-from portmaster@bsdforge.com) Received: from udns.ultimatedns.net (udns.ultimatedns.net [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TtKym3Bn9z452H; Mon, 11 Mar 2024 02:11:44 +0000 (UTC) (envelope-from portmaster@bsdforge.com) Authentication-Results: mx1.freebsd.org; none Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 42B2BLq1071030; Sun, 10 Mar 2024 19:11:36 -0700 (PDT) (envelope-from portmaster@bsdforge.com) List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Date: Sun, 10 Mar 2024 19:11:20 -0700 From: Chris To: Daniel Engberg Cc: Eugene Grosbein , Florian Smeets , ports@freebsd.org Subject: Re: Proposed ports deprecation and removal policy In-Reply-To: References: <435edf7c-a956-4317-b327-3372de70dbef@FreeBSD.org> <1c5b7818-842f-f7b8-9d4e-5bf681cad20e@grosbein.net> User-Agent: UDNSMS/17.0 Message-ID: <11e2ac939d635707da21a7037fb7412a@bsdforge.com> X-Sender: portmaster@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US] X-Rspamd-Queue-Id: 4TtKym3Bn9z452H On 2024-03-10 14:49, Daniel Engberg wrote: > On 2024-03-10T21:45:16.000+01:00, Eugene Grosbein > 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