Re: [GNU-linux-libre] Adding some scummvm game(s) to the "List of software that does not respect the Free System Distribution Guidelines"

[bill-auger]

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