On Thu, 22 Jun 2023 12:53:10 -0400 bill-auger <bill-auger@peers.community> wrote:
> i can answer some of those questions > > > On Wed, 21 Jun 2023 21:56:26 -0400 Richard wrote: > > Was it you who implemented this fix? You didn't say so; you said > > only that it had been fixed in Parabola. > > yes, that was all denis - he was also the most ardent about finally > moving forward on more of these TPPMs - the most popular examples are > removed now (pip and rubygems) I wasn't, I just wanted a consistent way to deal with third party package managers that didn't make the distribution explode and that was compliant with the FSDG. And if possible I also wanted to keep the ability to have FSDG compliant third party package managers (like Guix), but if removing that ability resulted in Parabola not exploding I was fine with it too and I would try to find other ways to make that use case work. For the background, I've started contributing to FSDG compliant GNU/Linux distributions precisely to try to enable people to easily run a given FSDG compliant distributions (Like Trisquel) in another FSDG compliant distributions (like Parabola) because it would make it easier for users to contribute to Replicant (that requires specific GNU/Linux distributions to build), and in the long run stop loosing some potential contributors to Replicant because of the complicated setup. But there is also more than one way to do that. Anyway having Parabola accidentally officially decide not to be FSDG compliant was not an option for me, so my actions made sure that there would at least be a discussion about it, in the hope of finding another way. At least that's how I perceived it at the time. But now I'm not so sure anymore that deciding officially to ignore the issue is not FSDG compliant. Here by ignoring the issue I mean not treating it as a bug that somehow needs solving. So if someone would have a fix, the fix would be rejected because there is nothing to fix, not because the fix is not good enough. So at the end I removed pip to show that there wasn't a consensus in Parabola and force discussions about third party package managers and FSDG compliance. I'm not happy about the outcome but from my point of view it was less worse than some of the other solutions like deciding to officially ignore the issue which I perceived as incompatible with the FSDG, and removing all third party package managers including the FSDG compliant ones which prevented many perfectly fine use cases. So again as long as the solution chosen is compatible with the FSDG, take care of users (warning them if necessary), and enable FSDG compliant third party package managers, I'd be more than happy with the solution. So if somehow adding back pip and rubygems is deemed OK for now, I'm not against that. And Parabola already has warning for users in the Parabola wiki[1], and there is a link to it in the wiki front page so that works for me. If we can also experiment with fixes that have the least amount of breakage for users use cases, that would also be great. In that case maybe having two packages could work? Having a "fixed" one and an "unfixed one". > FWIW, this already is "later" - we have been deferring to address > these for about 7 years now - o/c a bit longer wont hurt; but this is > a very large problem > - docker is only the tip of the proverbial iceberg Docker is easier to deal with than pip for instance, so making the right fix should be possible with not too much work. In addition if GNU sets up a docker repository then we'd have the best of all worlds. I even had an idea for the name for a project like that: GNU Wild (because it runs software in its natural environment but that is also wild for people using it because that software is not well integrated in their host distribution as a regular package). Though someone needs to find a way to run such public registry first. There are various free software for it but how to do that needs more investigations (or knowledge) than what I did so far. Like find what software does what, how to configure them, how to package them, etc. > the solution chosen for docker (as this thread is describing) was > "disable default URL, make user-configurable" - the solution chosen > for pip and rubygems was "remove TPPM - do nothing else" - both have > "FSDG-fitness: total" and were relatively easy to implement; but > neither are not the ideal options If you have ideas on how to do it better feel free to share them, because for me the proposed docker fix is close to ideal I think. It enables to tell users that they are on their own and to somehow curate one or more repositories of FSDG compliant images. It assumes that we don't care about supporting use cases that use non-FSDG distributions inside docker images. So maybe that's fine too if the distribution is 100% free and that nonfree repositories are not enabled but then it brings again a similar version of that discussion because that 100% free image would likely have software that refer to third party repositories that are not 100% free (like pip) or have options to enable nonfree repositories easily. Note that other software compatible with docker like Podman also enable users to configure the default repository, so I thought that the idea of the fix I had wasn't that bad because it would bring Docker on pair with Podman, though I didn't look precisely how Podman worked yet. References: ----------- [1]https://wiki.parabola.nu/How_does_Parabola_protects_users_against_nonfree_software Denis.
pgpOs6vbvilFi.pgp
Description: OpenPGP digital signature
