Date: Tue, 16 Nov 2021 01:14:23 -0500 From: "Mikhail T." <mi+ports@aldan.algebra.com> To: Daniel Engberg <diizzy@FreeBSD.org> Cc: "freebsd-ports@FreeBSD.ORG" <freebsd-ports@FreeBSD.ORG> Subject: Re: Regarding port(s) you maintain in FreeBSD ports collection Message-ID: <a1f15dbc-51e6-6ebd-5e57-14935da2f315@aldan.algebra.com> In-Reply-To: <a73b85b33a5e0b6ed61cb3e627165112@FreeBSD.org> References: <d8029a1dca2771ec0f7b9ca331488ea9@FreeBSD.org> <e0665090-7d17-c231-cafe-814bff599001@aldan.algebra.com> <a73b85b33a5e0b6ed61cb3e627165112@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------2XOkmYT0x0AmjRu1zbF0vtbZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------2XOkmYT0x0AmjRu1zbF0vtbZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a1f15dbc-51e6-6ebd-5e57-14935da2f315>