Re: Regarding port(s) you maintain in FreeBSD ports collection

On 13.11.21 15:51, Daniel Engberg wrote:
>
> I agree that old doesn't necessarily mean it's useless
>
Noted!

> however we do need to prune the ports from time to time
>
Why? Why do we need to "prune the ports from time to time"? I'm aware of 
one principle, under which a port can be deleted: the port remains 
broken for "too long". And even that principle is a little vague -- 
because "too long" is undetermined.

Not even having security problems is automatic grounds for removal -- or 
www/chromium would've been gone long ago :-) VuXML can (should!) flag 
the security flaw(s), but whether or not to use the port should be up to 
the user.

> a lot of these eats resources simply because they're not maintained in 
> our tree, upstream
>
Are you saying, resources are "eaten" because a port is not maintained 
upstream?! The worst resource-hogs currently are the LLVM, Rust (which, 
bizarrely, continues to build its own LLVM!), and webkits. All are 
actively maintained...
>
> and/or arguably may be seen as bad practice (depending on port) and so on.
>
I haven't seen any argument suggesting a "bad practice"... What are you 
referring to?

> Generally speaking it's also next to impossible to evaluate every 
> single port for runtime testing and improve the situation doesn't 
> improve when where are no "active" users.
>
This is difficult to parse, but you seem to mean, the ports you 
nominated for removal have no active ("active"?) users... How do you 
know this?
>
> I fully understand that this may not be in agreement with everyone and 
> we're open for discussion but simply hoarding ports / having a 
> "software museum" has been deemed to be not the way to go in agreement 
> with portmgr. It's a balancing act and I did look at other repos to 
> get a better grasp of ports I'm not all that familiar with.
>
Here you're implying authority of a portmgr -- are you a member? 
(Apologies for my being behind the staff appointments.) Yet, even 
portmgr should not be removing ports based on such vague arguments, 
whatever they "deem to be not". That body maintains the ports framework 
-- for them to declare certain ports less equal than others is an 
overreach... Though their Charter 
<https://www.freebsd.org/portmgr/charter/> grants them fairly wide 
authority, their stated goal is "to ensure that the FreeBSD Ports 
Developer community provides a ports collection that is functional, 
stable, up-to-date and full-featured". Removing ports -- other than for 
failing to build -- does not serve any of the enumerated objectives. 
Indeed, such removals violate the "full featured" part!

Frankly, I don't see anything wrong with a "software museum" -- 
anything, which a human being has once ported to FreeBSD, should remain 
ported (unless it breaks irreparably). Newer versions may, of course, 
push out the older ones, but that's about it...

> My reasoning regarding beecrypt was also based upon the fact that it's 
> no longer a port of many repos
>
Why is this relevant? Is FreeBSD being driven -- governed! -- by other 
"repos" (whatever that term means)? Is games/bsdgames found in any of those?
>
> There are no users except btcheck (optional and not enabled by 
> default) in tree
>
I can't help, but notice your shifting of the goal posts here. After 
conceding, that "old does not mean useless", you changed the argument 
for removal of beecrypt from "it is old" to "it is not used by other 
ports". And this new one is not a valid argument either...

There are no users of www/firefox in tree. Why is this relevant? It is a 
library -- for all you know, there may be multiple users with their own 
projects, that uses that library, why remove it, if it is not broken?

Must a port providing a software library be used by other ports? I'm 
unaware of any rule mandating this, are you? If you're not, why did you 
bring this up?

> Regarding www/websh its status is not going to change in agreement 
> with portmgr,
>
Here you're once again channeling portmgr. "Its status is not going to 
change," -- this is a tone of ruler condescending to speak to a 
subject... Are you alluding to some unpublished policy of portmgr? 
Because nothing of the kind is listed among the published ones:

    https://www.freebsd.org/portmgr/policies/

> it's obsolete and marked as dead upstream.
First of all, once again, I don't consider "obsolete" and "dead 
upstream" to be sufficient reasons for removal of a port. But even if 
they were, this does not apply to websh.

The "obsolete" part is simply not true -- websh is just as good as it 
was, when the last release was made. Tcl-8.6 remains the last release of 
the interpreter, and the port builds against the latest Apache. It also 
works (nicely) -- I use it on my own server.

I intend to add patches to ensure, the port builds with Tcl-8.7 as well. 
Maybe, this will make me the new "upstream" -- I hope, you don't mind...

> If you still want to keep obsolete software available as packages
>
In my opinion, people using packages should be using RPMs. The strength 
and the attraction of BSD in general, and FreeBSD-ports in particular is 
that everything builds /from source/ -- easily. But that's a different 
topic, let's not go off tangent...

> I suggest that you look into the overlay functionality for ports using 
> Poudriere.

My involvement with FreeBSD predates Poudriere by over a decade -- I 
hope, you don't imply, using the tool is mandatory for committers or 
users...

Yours,

    -mi