[GNU-linux-libre] third party package managers

[bill-auger]

On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote:
> PureOS probably doesn't need to ship CPU microcode updates.

that was why i mentioned it - that package is not part of pureos - it is kept
on a puri.sm server; so it never conflicted with the FSDG

puri.sm does have a desire to liberate the remaining blobs; but they are a
special case as a hardware vendor _and_ a distro - other distros are not likely
to ever liberate hardware


On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote:
> For Puri.sm hardware, Puri.sm can easily ship them in their Coreboot
> images instead, which are not part of PureOS.
> 
> Though I wonder if/they update their Coreboot image. Maybe they have
> some way to do it that is outside PureOS.

yes it looks like they have an coreboot/firmware update script, also not part of
pureos - i found some information:

https://puri.sm/faq/what-is-the-difference-between-libreboot-and-my-librems-coreboot-firmware/
https://puri.sm/projects/coreboot/


On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote:
> I think the key disagreement we have is if programming language
> repositories are useful or not.
> 
> If we assume that they are useless, then they could indeed be removed
> and the problem would also go away.

of course it is useful; but it is only a convenience for the distro to
distribute the package manager - they are very easy to acquire from the same
third-party - so regardless of utility, removing them from distros is not a
huge problem for anyone


On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote:
> I assume that they are badly needed, and that many users can't live
> without them and so they need fixing.

i think what youre really getting at, is that people will use them anyways,
whether the distro provides it or not; so it is better to use a more
freedom-respecting version from the distro

my counter-argument there, is that we do not know yet, if anyone would use a
libre-only version of pip or whatever - i looked at ruby one time - roughly
half of all packages were not licensed - that means a libre-only version would
be only half as useful

a typical webby application setup will install about 100 dependencies - if any
one of them is unavailable, that is a total deal-breaker for that person's
use-case - most likely, the user will try to install some webby thing, but some
dependencies will not be available - so that user, rather than decide not to
install that webby thing, will instead stop using the libre-only version, and
install the upstream version anyways

that really puts in doubt how much liberation effort the TPPMs deserve - let
alone to curate new libre-only repos, which maybe no one would use, because it
is likely to be missing _something_ for every application


On Mon, 31 Jul 2023 17:39:02 +0200 Denis wrote:
> A way to find out here would be to understand if FSDG compliant
> distributions users really use third party software, and what kind of
> software they use.

IMHO that was the most interesting goal of our experiment to remove pip and
rubygems - only a few people complained about pip - in reality, more people
objected before it was done, than who complained afterward - people complained
about rubygems, but only because it prints a warning message to the shell, not
because they wanted it back

users of FSDG distros definitely use third-party software - typically
applications (AUR packages, appimages, flatpacks); so that concern (who would
miss them and why) could be considered as two broad categories: (language
library TPPMS, and application TPPMS)

the language TPPMS are normally used for installing an enormous number of
packages; so they are notably worse - also the language TPPMS are normally used
by the more tech savvy people, who would have no trouble installing the
upstream's package manager if the distro does not provide it

the application TPPMS are normally used by non-technical users, for installing
a relatively small number of packages (though instide you will probably find
much more than a single application) - i see that more often with LTS distro
users, to get a newer version of an application which is in the distro repos as
an older version

for that reason alone, i would focus first on those (docker, flatpack,
appimange, etc) - those are probably more desirable overall - i doubt if any
parabola users would complain; because they can get all those applications from
the AUR, so deleting them from parabola may not reveal any new information - a
distro like trisquel would need to run that experiment

so again, that work would be done primarily for other distros - parabola does
not really need third-party application installers for twi reasons - A)
parabola's application are the newest they can be - B) the AUR is a much better
source for anything else, because the application gets built from source, and
parabola has a native tool to build them easily - i would much rather tell
parabola users never to use a flatpak or similar, but to grab a PKGBUILD from
the AUR instead, or make a packaging request