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

Reply via email to