Am Sun, 16 Jun 2024 11:32:02 +0200 Harry Schmalzbauer <free...@omnilan.de> schrieb:
+1 > Please stop removing perfectly working ports from the tree. > > textproc/obsidian is the latest victim, just because it currently > depends on devel/electron25 - which builds and runs perfectly well too. > User can in-app update obsidian. > If the package building team already blacklisted devel/electron25 to > circumvent interference, why not keep it that way? > > Historically, ports tree was for the users, not for the package building > team. It worked well like two decades for both parties, but the last > two years there were many ports killed for no reason, resp. by > completely meaningless justifications like 'it's old' - there haven't > been new upstream commits for years. > There is the BROKEN variable for the reason that even non perfectly > working ports can be kept in the tree to be discovered by fellows having > time to fix it. Erasing work which people already invested to create a > port is for no benefit to anybody/anything. Not only "historically", we've choosen the make framework way to build ports due to a lot of customised ports and the load of poudriere build farms creating packages is in some cases an overkill - and too fragile. > > Let it up to the users' decision how they want to deal with 'pkg audit' > results. > There are people running FreeBSD offline - because FreeBSD can be kept > offline easily and it's easy to run your own package building > environment - even installing ports without building packages still is > an option today. Offline usage is sometimes enforced by security rules to obey. Scanning an filtering the framework and tarballs is sometimes much easier to accomplish than doing so with blobs. > The new habit of ports tree cleanup does harm that outstanding FreeBSD > feature and just boosts the disadvantage over Linux that we don't have > applications available which are available on Linux. Maybe Linux lovers/developers acting as FreeBSD committer ... ? ;-) Conflict of interests. Sorry ... > > I vote for needing explicit maintainer approval before anyone is allowed > to remove any ports from the tree. > If the current maintainer isn't responding or a specific port doesn't > have a maintainer, the users' should have a veto option at least. > Blindly removing ports is counter productive to the project, imho. > > -harry > > -- O. Hartmann