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

On 2021-11-16 07:14, Mikhail T. wrote:

> 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 [1] 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

Hi Mikhail,

There are numerous of reason why we need to remove ports, one major 
reason is simply to have a sustainable repository. One example is the 
deprecation of Python 2.x which is long overdue but we're slowly getting 
there because there still are a few crucial pieces of software that 
depends on it such as Chromium. When upstream decides to drop support it 
essentially falls into the hands of maintainers of said package(ing) 
repo to make sure that it builds, runs as expected, perferably have the 
ability to audit so its safe to use to name a few. Thankfully we have a 
great community of committers and contributers who engages and helps out 
with these issues but at some point it's no longer viable and/or little 
to no benefit. Such decisions like this one are run by several members 
and portmgr to ensure there's a general agreement and to get feedback in 
case you've overlooked something that may be of value and listening to 
community feedback. While it's near impossible to meet everyones 
expectations its high up on the list to do so however inevitably there 
will also be disagreement.

In this case to be more specific I used Repology (repology.org) as a 
gauge along with a few other aspects such as its purpose, upstream 
support and acitivity to evaulate a reasonable course of action which I 
think is fair. Whether a port is a standalone application or library 
wasn't something I took into consideration however if one affects 
multiple of users in tree further evaluation might needed to take into 
consideration.  It is indeed hard to estimate amount of users which is 
why I reached out on -ports mailinglist and by mail to listed 
maintainers asking for feedback and a reasonable argument.

While there's no hard requirement to use Poudriere it does however speed 
up the submission process and is a requirement that your port builds 
using it [1]. The transition to git also makes it possible to maintain 
your own modifications to the tree easily.

[1] 
https://docs.freebsd.org/en/books/porters-handbook/book/#testing-poudriere

Best regards,

Daniel

Links:
------
[1] https://www.freebsd.org/portmgr/charter/