On Mon, 12 Jun 2023 17:37:39 -0400 John wrote: > But saying the absence of published and > shared free extensions/plugins/whatever and the presence of proprietary > extensions/whatever means that a free thing that is already packaged > should be unpackaged makes no sense to me.
i dont remember anyone suggesting that - we seem to be kicking a straw-man around - IIRC, i was the only one who suggested excluding it, but not as a general rule - that was on the basis of work-load/desirability - it consumes resources, with no indication that anyone wants to use it - like a shop-keep deciding to stop stocking caviar, because no one has bought caviar from that shop since 1998 On Mon, 12 Jun 2023 17:37:39 -0400 John wrote: > Manually maintaining some things on a system while > other things are packaged is a notoriously fraught thing to do. > Packaging is an important and valuable convenience that eliminates a lot > of yak shaving. maybe this point is not so obvious; but i am admittedly biassed on that concern - parabola users can package their own software easily and robustly, for anything which is not in the binary repos - they do not even need to understand how the recipe works - any niche or otherwise unpopular software like scummvm, will be available as a recipe, for as long as even one user of an arch-like distro wants to use it - the recipe maintainer ensures that it remains viable (aka: fool-proof) - an interested user needs only to grab the recipe and type `makepkg -sri` in fact, that is how most binary packages enter the system - recipes begin as user-maintained recipes; then other users vote for their favorites - if one recipe receives enough votes, it is adopted as a binary package - but when the day comes that it no longer justifies the work-load, it is reverted back to the user-maintained recipe pool, where it will stay, until literally no one wants it anymore, possibly longer IMHO, that packaging life-cycle makes the arch ecosystem superior to larger distros such as debian, which carries ~80,000 binary packages - that user-maintained recipe pool contains 85613 package recipes today - add that to the ~20,000 binary packages maintained by the diatro, and users of arch-like distros have a larger software selection "at their fingertips" than users of debian-like distros; yet the distro maintainers only need to maintain and distribute the small subset of the essential and most popular packages so for parabola, the decision to drop a binary package is mostly inconsequential to users, unless it is something essential like glibc - but it saves workload and computing resources for the distro and mirrors, albeit at the expense of a negligible inconvenience to a negligible number of users who want to use it