From nobody Sat Mar 09 12:10:59 2024 X-Original-To: freebsd-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 4TsMMD3tGyz5D2sl for ; Sat, 9 Mar 2024 12:11:04 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from smtp-190a.mail.infomaniak.ch (smtp-190a.mail.infomaniak.ch [185.125.25.10]) (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 (2048 bits) client-digest SHA256) (Client CN "relay.mail.infomaniak.ch", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TsMMB3nk1z4Z3x for ; Sat, 9 Mar 2024 12:11:02 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pyret.net header.s=20231006 header.b="Mf3YIii/"; dmarc=pass (policy=reject) header.from=pyret.net; spf=pass (mx1.freebsd.org: domain of daniel.engberg.lists@pyret.net designates 185.125.25.10 as permitted sender) smtp.mailfrom=daniel.engberg.lists@pyret.net Received: from smtp-4-0001.mail.infomaniak.ch (unknown [10.7.10.108]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4TsMM74LJdzMpvb3 for ; Sat, 9 Mar 2024 13:10:59 +0100 (CET) Received: from unknown by smtp-4-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4TsMM71hH3zdpN for ; Sat, 9 Mar 2024 13:10:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pyret.net; s=20231006; t=1709986259; bh=CSYv/Ocgk5YR4I9Y3sblvbTPGRi/yaBEhQdVgJMUf9s=; h=Date:Subject:From:Reply-To:To:From; b=Mf3YIii/AnRyC09sW/zbu6R4JcMShwE0xmQmSW1vrUMm4CnVIr7gkUptjCIK/gyXd rNY0WQoSA0dsRWmyChribstJXd7nMerppELUo0C+5f1NDBOh+8zK3hScdoy3rNAj6/ lexvSb+66bGDC7R0ktVfiopFPffzm+Z39DuHL0Xy2XweryyDfLessD/QSZNI/IEwIQ hzgrQ110PNAbWj16ecB9j5hoTqqrwGhlMD4hbc9v7/pma5KKNVYM5eiJSa4DMriuK3 ByV6UeOlm0uXt8MihyxHPpdLgsXAc5pD4clqYUfaFzMoYQ1F6/LeFEuEaxS3NYG/5b L/ojnqZCvGbgw== Message-ID: <74daf1cedbb492454101b4f196129335@mail.infomaniak.com> Date: Sat, 09 Mar 2024 13:10:59 +0100 Subject: Re: Proposed ports deprecation and removal policy From: Daniel Engberg Reply-To: Daniel Engberg To: "freebsd-ports@freebsd.org" 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-WS-User-Origin: eyJpdiI6InNzS2tiNW9HQkMyenhxRW85RVVuVnc9PSIsInZhbHVlIjoiZ1hqb2tUeVN0K0dsdHVMemZmZzB2UT09IiwibWFjIjoiYjM4OTRhMjY5ZjBhYTQ0Yzk3Y2JhZTFkN2RiMjY5ODZlZmU0Nzc4ZmJkZDA0OWUwNjhkZGVmYTQ2ZGE4ZmYwMiIsInRhZyI6IiJ9 X-WS-User-Mbox: eyJpdiI6IjdqV0RWOFlKRG1TWjVmUTNNbU0wYVE9PSIsInZhbHVlIjoiejZWUmZmNDhwalpGd0QvUVkwYWozUT09IiwibWFjIjoiY2ExMjRmN2E5ZDIwNTdjMTNiOTY3NTYwNzQyMjM0MmUxOGVjNzgxN2NmZDllMjQ1MzJmMWVhMjVmOTc3ZjIzNSIsInRhZyI6IiJ9 X-WS-Location: eJxzKUpMKykGAAfpAmU- X-Mailer: Infomaniak Workspace (1.3.651) X-Infomaniak-Routing: alpha X-Spamd-Bar: - X-Spamd-Result: default: False [-1.30 / 15.00]; THREAD_HIJACKING_FROM_INJECTOR(2.00)[]; FAKE_REPLY(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW(-0.50)[pyret.net,reject]; RWL_MAILSPIKE_VERYGOOD(-0.20)[185.125.25.10:from]; R_SPF_ALLOW(-0.20)[+ip4:185.125.25.8/29]; R_DKIM_ALLOW(-0.20)[pyret.net:s=20231006]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[185.125.25.10:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[daniel.engberg.lists@pyret.net]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[pyret.net:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; ASN(0.00)[asn:29222, ipnet:185.125.24.0/22, country:CH]; REPLYTO_EQ_FROM(0.00)[] X-Rspamd-Queue-Id: 4TsMMB3nk1z4Z3x Hi, A few comments on the proposed ports deprecation and removal policy, there = will be some quotes for context by multiple people and adress multiple mail= s. I would recommend that we in general set DEPRECATED, EXPIRATION_DATE (2w t= o 1m minimum), mark BROKEN if needed before removal to avoid unnecessary fr= ication and give people a chance to raise a discussion if needed. Possibly = with the exception of major library updates etc or perhaps if we have a rea= sonable threshold. I do however think that people in general surpass the ex= ceptions of keeping ports buildable without deprecating even today. > - Upstream distfile is no longer available from the original source/mirro= r (Our > andother distcaches e.g. Debian, Gentoo, etc do not count as "available"= ) Agreed, in addtion it can be an indication that upstream is dead/inactive/a= bandoned project but you as a committer should be able to determine the cur= rent situation without spending too much time on it. I honestly think we ca= n leave it up the committer as at least myself would trust people to have a= suitable threshold (a few days or so) rather than something ridicious like= 1h or so. This will of course also include an overall review of the "usability"/usefu= lness and if it's maintainable. For example, if lets say telnet client (I'm= aware its not a port but for the sake of giving an example) upstream site = goes away it may be worth rehosting it as it's likely not going to change, = evolve or cause major maintenance issues (noise) further down the road and = is still of use. If it's a WAP (the old Wireless Application Protocol) spec= ific server daemon that would on the other hand be reasonable to consider d= eprecating. At the end it all boils down to doing a resonable assessment=20 > - Upstream WWW is unavailable: deprecate, remove after 3 months Older but still useful ports may not have one, perhaps have a universal tag= to easily tag such ones? WWW=3D LEGACY-BLANKET-UNAVAILABLE or something along those lines? > -has known vulnerabilities that weren=E2=80=99t addressed in the ports tr= ee for=20 > more than 3 months As for security issues as people have discussed far from all are reported a= s CVEs despite being pretty serious.=20 Examples:=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264186 --> https://github.com/mikebrady/shairport-sync/issues/1478, audio/alacenc --> https://github.com/flacon/alacenc/issues/1 So it shouldn't be CVEs alone > This policy should give some guidance on when ports can or should be=20 > removed. In general ports should not be removed without reason but if a= =20 > port blocks progress it should be deprecated and subsequently removed.=20 > In general, if a ports blocks progress for some time it will be removed= =20 > so that progress can be made. For more details see below. > The phrasing "blocks progress" is problematic. Progress of what?=20 > Indiscriminately hunting down EOL/apparently inactive software? Mass=20 > migrating from one build system to another due to primarily personal=20 > preference, even against upstreams' will? This phrasing is vague enough= =20 > to justify deprecating and removing, say EOL (but still fetchable and=20 > buildable) libraries needed by actively-maintained and supported (and=20 > popular) software that are in no rush to migrate away. If this vagueness= =20 > is intended, then it needs to be accompanied with *us* actively=20 > developing in the upstream project to support efforts here. This fall upon the committer to be reasonable, if a project is still stuck = on lets say boost 1.66 and falls under the not active section than it's sub= ject to removal. There will of course be some edge cases that affects many = and/or the projects infrastructive that need a more public discussion (a re= asonable delay to catch up) but in general there shouldn't be any issues in= general with this policy. For recent examples audio/taglib (PR 276677) and multimedia/ffmpeg (PR 2613= 02) are good acceptable ways of handling these types of issues in general. We do need to sunset ffmpeg4 eventually however... We do forking with multiple versions at times but those seem to cause more = issues that they solve and often conflicts with each other. Concerning ports the depends on software that's EOL This fall upon the committer to be reasonable, if a project is still stuck = on lets say boost 1.66 and falls under the not active section than it's sub= ject for removal. There will of course be some edge cases that affects many= and/or the projects infrastructive that need a more public discussion (a r= easonable delay to catch up) but in general there shouldn't be any issues i= n general with this policy. For recent examples audio/taglib (PR 276677) an= d multimedia/ffmpeg (PR 261302) are good acceptable ways of handling these = types of issues in general. We do need to sunset libraries such as ffmpeg4 = eventually so it's not a long term solution. EOL dependencies are considered unmaintained and officially unsupported, of= course a reasonable amount of time (a few months) should be allowed for up= stream to catch up but otherwise the port should go as it's very likely to = have security issues, build and maintainability among other concerns. If sp= ecific users feel there's a need to keep the port and its dependencies Poud= riere supports overlays so they can still continue to use it outside the of= ficial tree. There could even potentially be an unofficial overlay outside = the project called ports-legacy-overlay or whatever that's maintained by th= e community if there's interest. We wont be able to cater everyones specifi= c needs but we can however try to make a best effort about it within reacha= ble limits. It's very easy to claim that we should support * until the end of time but = that's not being realistic and in most cases originates from lack of mainta= ince upstream for one or another reaon or within the tree. We already have = an uphill battle with several ports trying to keep them at least buildable = due to this. What happens in practice that people trying to keep these libr= aries up to date will eventually burn out or lose interest prematurely. It = should also be mentioned that buildable doesn't necessarily mean functional= and it's not a software museum. > - Software hasn=E2=80=99t seen a release in a long time > - Upstream looks inactive for a long time This is problematic in practice as that doesn't cover abandonware and simil= ar situations a upstream project may be in but rather protects all ports in= cluding those that have a maintainer but is inactive. I do agree on that a = port per se shouldn't be removed determined by its age alone. A few aspects that should be included and taken into consdieration:=20 - Deprecated in terms of coding (we need to manually patch it from time to = time in order to keep it buildable) - Obvious bad practice, example VPN software only supporting DES for encryp= tion - Counterparts/replacements are available (either within ports or outside a= nd are somewhat closely similar) Note: While I don't think we should dictate what users should/shouldn't do = I think there is some "responsibility" implied as we do have a "Ports Secur= ity Team" regarding this topic - "Cruft", obsolete stuff that has little to no value today. Such as "netbu= s" (Windows) clones, software for interfering with 15+ old MP3 devices or a= n abandoned VCS There should always be a PR created (if maintained) and/or a resonable exp= iration date if people want to raise discuss the decision with fair argumen= ts I still feel much of this falls under the "being reasonable" with the commi= tters discretion in mind in the end. A deprecation notice "bot" sounds like a good idea like delphij@ suggested I would also raise concerns about one man band forks regarding abandonware,= some projects flat out refuse these in their guidelines and for most of th= e time it's likely justified. While I dont think necessarily there's a need= to refuse these I would also on the other hand be reluctant to define thes= e as "maintained" as a way to work around policies just because or even ad= d these to the tree in the first place. As for the ongoing work in general, I've tried to keep an open dialog about= it and the majority of interractions have been very been positive overall.= We do however carry a bunch of lang related ports (p5, php, python etc) t= hat needs to be looked at some point. Best regards, Daniel (diizzy@)