Re: [GNU-linux-libre] third party package managers

[Denis 'GNUtoo' Carikli]

On Tue, 1 Aug 2023 01:58:10 -0400
bill-auger <bill-auger@peers.community> wrote:

> 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
Even if it's software I don't think that it has been packaged, and if
it is, it would probably be packaged for other distributions than PureOS
(like Pureboot or other distributions that allow nonfree software).

And this problem is not directly related to the FSDG.

To put things into perspective, with computers that have 100% nonfree
boot software (BIOS, UEFI), and/or that have ATI/AMD and Nvidia
GPUs, users of FSDG distributions also run nonfree software. 

That software isn't provided by the distribution but it is bundled in
the hardware. Here are two very common examples:
- The boot software exports ACPI bytecode that the kernel runs. When
  the boot software is 100% nonfree, that bytecode is also nonfree.

- Removable GPUs contain code that is run by the boot software (even
  if the boot software is free it still runs this code). Then the
  radeon/amdgpu/nouveau kernel drivers run some nonfree bytecode
  (called AtomBIOS for ATI/AMD) that is exported by these GPUs to
  initialize them.

This also why there is a RYF certification: FSDG and RYF are
complementary.

So maybe you were trying to describe the fact that users are not
informed about all that. And I think this is a real issue but the
way to fix that is precisely to find ways to inform users as PureOS
seems to do things correctly here.

In fact you can even use PureOS on some RYF compliant computers.

> 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
Replicant liberates hardware. But it's also very different since it's
an Android distribution. I applied for funding through NLnet again
and part of the work will be to close more the gap between Android and
GNU/Linux by improving collaboration with various upstream projects.

> 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/
Thanks.

> 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
I think it depends:
- After I removed rubygems in Parabola, most Ruby programs don't work
  anymore as import fail. There is probably a better way to do that
  though but I don't know how and I didn't have the time to look into
  it.

- Guix probably uses these package managers for guix import, so
  simply removing them will affect that functionality, though there is
  probably a way to hide the package to users but still enable Guix
  import to use it. But here my point is that a rule to remove them all
  blindly won't work here.

- Dragora and Guix are not FHS compliant, so users can't easily
  download these package manager from the programming language website
  and run them.

- Not all programming language package manager easily be installed
  by users. With rust (rustup), python (pip), the tool is widely
  publicized and on the tool website there are instructions and a
  script to install it on top of a GNU/Linux distributions. But that
  might not be the case for all languages. I didn't find how to install
  rubygems for instance.

All of these situations are not an issue anymore if these package
managers point to FSDG compliant repositories.

> 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
Here if we assume that they are not useful, then removing them does make
sense as it fixes the distribution really fast and the problem goes
away.

But if we assume that they are useful, we get the opposite conclusion
as freedom-respecting versions of these package managers is worth
having I think. But alone, that reasoning by itself cannot tell what is
more important between having the distributions fixed now and having the
distributions fixed later and having freedom-respecting versions of
these package managers. For that we need more context, users input, etc.

> 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
I've had the use cases for the go package manager.

I sometimes want to try some software like docker-registry that isn't
packaged in any FSDG distribution, to see if it fit my use case.

So without a programming language package manager I end up wasting lot
of time packaging software just to test it, and I do that because it's
faster to make a package than to build that software by hand.

But making a package is order of magnitude slower than just typing one
command like 'go get registry' to install and test it.

And here at the end I found out that docker-registry wasn't as useful as
I assumed it was.

> 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
What is a webby application? Is it something like mediawiki? Or is it
some electron application? Or both?

In any case if the application cannot be installed in the 100% free
version of the programming language repository, it will signal the user
that there is potentially a problem. 

If the user looks into it and finds nonfree dependencies, it would
give the user power to fight back:
- Even if the user is pushed to use that application as part of work,
  or collaboration in other structures, the user can more easily refuse
  to use it or refuse to make the organization depend on it on the
  basis that it doesn't work without nonfree software, similar to the
  Java Trap. The user could also raise legal issues and show that
  there is a problem, etc, pushing the organization to refuse to use it
  or depend on it.
- The issue could be publicized in the hope that either the issue
  is fixed, or to give more leverage to people to resist against
  depending on that application.

Instead without any information that proves that the application is
nonfree people not wanting to depend on nonfree software would have a
harder time convincing other people that there is indeed a very serious
problem and that they are not paranoid or too strict.

Here I would also have used that to understand if some web applications
were really free software to warn people I know that were deploying
them.

> 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
About rubygems I got only 1 complaint in person at the FOSDEM 2023. I
also found after that it broke ruby packages so I now officially
complain too (even if I did that change).

Now these changes for programming languages were done in Parabola only,
and there are distributions with more users (at least Trisquel) and more
diverse user groups (Guix, Trisquel, PureOS) where such changes could
have very different effects.

> 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)
There are also games, in-applications plugins, etc. This issue touches
a wide variety of software.

> 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
I'm unsure if people wanting that are that tech savvy. If they aren't
then pointing them to upstream documentation on how to install these
upstream package managers (that have repositories with nonfree
software) is not allowed by the FSDG for good reasons.

Instead if we have FSDG compliant programming language package
managers, and that they also release versions that can be installed on
top of any distributions, then distributions like Parabola could simply
point to installation instructions of these package managers. 

In addition it would make it easier for people to adopt them, including
on top of non-FSDG compliant distributions. So they would be able to
know if what they depend has nonfree dependencies or not etc.

> 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
Fedora has an interesting approach where some of the packages of the
newer versions of Fedora are also available as flatpak so they can be
installed on top of LTS distributions.

I personally would like the FSDG distributions to also do that so
people can also get more recent FSDG compliant packages without
upgrading everything.

We already have Guix that can do that but it requires at least to know
well the command line and to know of how GNU/Linux works to use it on
top of another distribution as you'll need to handle the integration
inside the distribution (like change the PATH, source files, etc).

> 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
For Parabola I advise users to:
(1) Manually download from Aur the package definition and their package
    definition for the dependencies. That can be long though but (2) is
    longer anyway.
(2) Review the freedom of all that (check licenses, check source code
    for suspicious things, check if the license is properly declared in
    the source code, etc).
(3) Ideally send patches to Parabola to add all that in the PCR
    repository, so that everybody can install that software and know
    that it has got some sort of review.
(4) Ideally from time to time send patches to update the packages to
    the latest versions.

Without (3) and (4), it would not be that great as (1) and (2) can take
quite some time for software with a lot of dependencies.

Denis.

pgpXUc98RdvDu.pgp
Description: OpenPGP digital signature