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/
